11
datensätze pro kunde nummerieren
Hallo zusammen,
stehe irgendwie grad auf dem Schlauch
also ich habe eine Tabelle, in der verschiedene Rechnungen (Rech_Dat und Rech_Betr) pro Kundennummer aufgelistet werden. Diese Rechnungen will ich jetzt einfach abhängig von der Kundennummer durchnummerieren. Genauer soll das erste Rechungsdatum eines Kunden die 1 erhalten das zweite die 2....
wie das passiert, sql oder funktion is völlig wurscht....
hab wahrscheilich die osterfeiertage noch nicht richtig verkraftet,
hoffe ihr könnt mir kurz mal helfen^^
Grüße marc
stehe irgendwie grad auf dem Schlauch
also ich habe eine Tabelle, in der verschiedene Rechnungen (Rech_Dat und Rech_Betr) pro Kundennummer aufgelistet werden. Diese Rechnungen will ich jetzt einfach abhängig von der Kundennummer durchnummerieren. Genauer soll das erste Rechungsdatum eines Kunden die 1 erhalten das zweite die 2....
wie das passiert, sql oder funktion is völlig wurscht....
hab wahrscheilich die osterfeiertage noch nicht richtig verkraftet,
hoffe ihr könnt mir kurz mal helfen^^
Grüße marc
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113772
Url: https://administrator.de/forum/datensaetze-pro-kunde-nummerieren-113772.html
Ausgedruckt am: 05.04.2025 um 02:04 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
bitte mal konkreter ... Excel, Access, MySQL ....
Ein Auszug aus der Tabelle ...
Gruss
bitte mal konkreter ... Excel, Access, MySQL ....
Ein Auszug aus der Tabelle ...
Gruss
achso, entschuldigung, dachte ich hätte das direkt unter office- access gepostet,
es handelt sich um access, und die wichtigen Tabellenfelder sind Knd_Nr(LongInteger) und Rech_Dat(Datum).
der Hintergrund dieser Übung ist, das ich die einzelnen Rechnungen pro Kunde durchnummerieren will, um später die Letzte Rechnung, dann die Vorletzte Rechnung usw abzuarbeiten.
Die späteren Berechnungen hab ich schon im groben geplant, hab nur mit dieser dummen Nummerierung der Rechnungen Probleme.
es handelt sich um access, und die wichtigen Tabellenfelder sind Knd_Nr(LongInteger) und Rech_Dat(Datum).
der Hintergrund dieser Übung ist, das ich die einzelnen Rechnungen pro Kunde durchnummerieren will, um später die Letzte Rechnung, dann die Vorletzte Rechnung usw abzuarbeiten.
Die späteren Berechnungen hab ich schon im groben geplant, hab nur mit dieser dummen Nummerierung der Rechnungen Probleme.
Hi !
Von einem Primärschlüssel hast Du noch nichts gehört oder habe ich da jetzt was falsch verstanden ?
mrtux
PS: Ausserdem würde ich mal eine richtige Datenbank verwenden. A* ist ne mittlere Katastrophe.
Von einem Primärschlüssel hast Du noch nichts gehört oder habe ich da jetzt was falsch verstanden ?
mrtux
PS: Ausserdem würde ich mal eine richtige Datenbank verwenden. A* ist ne mittlere Katastrophe.
hm, keinen Plan was der Primärschlüssel mit meiner Frage zu tun hat,
aber naja,
danke für die hilfreichen antworten, habs jetzt selber
Grüße
aber naja,
danke für die hilfreichen antworten, habs jetzt selber
Grüße
Hi !
Also ich würde die Datensätze durchnummerieren und üblicherweise liegt auf diesem Feld dann auch der Primärschlüssel oder was meintest Du sonst mit durchnummerieren?
Hellsehen kann ich noch nicht, deshalb auch die Frage ob ich das richtig verstanden habe ?
mrtux
hm, keinen Plan was der Primärschlüssel mit meiner Frage zu tun hat,
Also ich würde die Datensätze durchnummerieren und üblicherweise liegt auf diesem Feld dann auch der Primärschlüssel oder was meintest Du sonst mit durchnummerieren?
Hellsehen kann ich noch nicht, deshalb auch die Frage ob ich das richtig verstanden habe ?
mrtux
Moin der.Huefti,
so sehr ich auch sonst oft darum bettele, dass hin und wieder mal ein "Erledigt"-Haken an den einen oder anderen Beitrag kommt, so bin ich doch in diesem Fall eher unglücklich damit.
Weil....
erstens)
Deiner Beschreibung nach existiert doch ein eindeutiger Primarykey (Rech_dat und Knd_Nr).
Dieser hätte doch bestenfalls den unangenehmen Nebeneffekt, dass mehrere Rechnungen pro Tag für einen Kunden nicht möglich wären.
Okay, das wäre mir zu heiss, und ich würde also irgendeine künstliche "Rechnungsnummer" (also fortlaufende Nummer mit einem Phantasiepräfix wie "0922" vorweg einbauen.
Aber die "laufende Rechnungsnummer je Kunde", die Du da jetzt reinbastelst, die behebt ja kein Problem, sondern ist einfach nur redundant.
Die brauchst Du auch nicht speichern, sondern kannst sie immer reproduzierbar mit einer einfachen Abfrage erzeugen.
Von daher machst Du doch durch die Speicherung dieses Null-informations-Berechnungsfelds eher noch einen Rückschritt, was das Design angeht.
zweitens) finde ich es immer unbefriedigend, wenn jemand postet "Ist erledigt, habe selbst eine Lösung gefunden. Ciao"
@mrtux
Die Frage nach dem PK war berechtigt, aber...
Grüße
Biber
so sehr ich auch sonst oft darum bettele, dass hin und wieder mal ein "Erledigt"-Haken an den einen oder anderen Beitrag kommt, so bin ich doch in diesem Fall eher unglücklich damit.
Weil....
erstens)
Deiner Beschreibung nach existiert doch ein eindeutiger Primarykey (Rech_dat und Knd_Nr).
Dieser hätte doch bestenfalls den unangenehmen Nebeneffekt, dass mehrere Rechnungen pro Tag für einen Kunden nicht möglich wären.
Okay, das wäre mir zu heiss, und ich würde also irgendeine künstliche "Rechnungsnummer" (also fortlaufende Nummer mit einem Phantasiepräfix wie "0922" vorweg einbauen.
Aber die "laufende Rechnungsnummer je Kunde", die Du da jetzt reinbastelst, die behebt ja kein Problem, sondern ist einfach nur redundant.
Die brauchst Du auch nicht speichern, sondern kannst sie immer reproduzierbar mit einer einfachen Abfrage erzeugen.
Von daher machst Du doch durch die Speicherung dieses Null-informations-Berechnungsfelds eher noch einen Rückschritt, was das Design angeht.
zweitens) finde ich es immer unbefriedigend, wenn jemand postet "Ist erledigt, habe selbst eine Lösung gefunden. Ciao"
@mrtux
Die Frage nach dem PK war berechtigt, aber...
PS: Ausserdem würde ich mal eine richtige Datenbank verwenden.
Na ja, in der Design-Phase hätte auch eine echte Datenbank nichts gegen redundante Felder geholfen.A* ist ne mittlere Katastrophe.
Demnach gibt es auch größere Katastrophen??Grüße
Biber
Morgen,
also erstmal sorry für meine etwas barsche Antwort, allerdings finde ich Antworten wie .. benutz doch mal eine richtige Datenbank.. total sinnlos, weils mich kein stück weiterbringt und nur spam is....
und zu meinem Problem:
es existiert ein unabhängiger Primärschlüssel, da wie ihr schon festgestellt habt, auch mehrere Rechnungen/Gutschriften pro Tag und Kunde eingehen können. Ich habe einfach nach einer allgemeingültigen Methode gesucht um mein Problem zu lösen, ohne das ich euch jetzt meine Tabellenverknüpfungen alle einzeln erklären muss. Die Rechnungen sollen pro Kunde durchnummeriert werden, um sie der Reihe nach abarbeiten zu können.
allerdings habe ich bereits eine Lösung gefunden, die ähnlich einem existierendem Post ist :
Fortlaufende Nummer in Access (kein AutoWert...)
leider habe ich diesen erst später gefunden...
Nix für Ungut,
Grüße Huefti
also erstmal sorry für meine etwas barsche Antwort, allerdings finde ich Antworten wie .. benutz doch mal eine richtige Datenbank.. total sinnlos, weils mich kein stück weiterbringt und nur spam is....
und zu meinem Problem:
es existiert ein unabhängiger Primärschlüssel, da wie ihr schon festgestellt habt, auch mehrere Rechnungen/Gutschriften pro Tag und Kunde eingehen können. Ich habe einfach nach einer allgemeingültigen Methode gesucht um mein Problem zu lösen, ohne das ich euch jetzt meine Tabellenverknüpfungen alle einzeln erklären muss. Die Rechnungen sollen pro Kunde durchnummeriert werden, um sie der Reihe nach abarbeiten zu können.
allerdings habe ich bereits eine Lösung gefunden, die ähnlich einem existierendem Post ist :
Fortlaufende Nummer in Access (kein AutoWert...)
leider habe ich diesen erst später gefunden...
Nix für Ungut,
Grüße Huefti
Hi Biber,
Bingo Biber !
Daher habe ich mich gewundert bzw. gedachte ich hab die Sache nicht verstanden.
Siehe weiter unten.
100% Zustimm, dagegen hilft nur, es eben ohne Redundanz ahem zumindest zu versuchen
Ohjaa aber ich hüte mich da Namen zu nennen, sonst entsteht gleich wieder tonnenweise "meine Datenbank ist die beste" Traffic hier im Forum.
Was mir jedoch in meiner Funktion als Admin immer wieder begegnet und ärgert ist, dass es heute wirklich gute und "günstige" (echte) Datenbanken gibt aber leider immer noch mit A..... rumgezimmert wird, nur weil die Leute nicht in der Lage sind mal über den Tellerrand zu schauen. So nach dem Motto: "Haben wir früher schon so gemacht, da bleiben wir dabei."
mrtux
jetzt reinbastelst, die behebt ja kein Problem, sondern ist einfach
nur redundant.
nur redundant.
Bingo Biber !
Die brauchst Du auch nicht speichern, sondern kannst sie immer
reproduzierbar mit einer einfachen Abfrage erzeugen.
reproduzierbar mit einer einfachen Abfrage erzeugen.
Daher habe ich mich gewundert bzw. gedachte ich hab die Sache nicht verstanden.
@mrtux
Die Frage nach dem PK war berechtigt, aber...
> PS: Ausserdem würde ich mal eine richtige Datenbank
verwenden.
Die Frage nach dem PK war berechtigt, aber...
> PS: Ausserdem würde ich mal eine richtige Datenbank
verwenden.
Siehe weiter unten.
Na ja, in der Design-Phase hätte auch eine echte Datenbank
nichts gegen redundante Felder geholfen.
nichts gegen redundante Felder geholfen.
100% Zustimm, dagegen hilft nur, es eben ohne Redundanz ahem zumindest zu versuchen
Demnach gibt es auch größere Katastrophen??
Ohjaa aber ich hüte mich da Namen zu nennen, sonst entsteht gleich wieder tonnenweise "meine Datenbank ist die beste" Traffic hier im Forum.
Was mir jedoch in meiner Funktion als Admin immer wieder begegnet und ärgert ist, dass es heute wirklich gute und "günstige" (echte) Datenbanken gibt aber leider immer noch mit A..... rumgezimmert wird, nur weil die Leute nicht in der Lage sind mal über den Tellerrand zu schauen. So nach dem Motto: "Haben wir früher schon so gemacht, da bleiben wir dabei."
Grüße
Biber
Biber
mrtux
Moin mrtux,
okay, Deine Einschätzung bzgl. MSAccess ist nicht völlig unbegründet...
Aber (ja, manchmal nehme sogar ich diese Redmonder in Schutz) man/frau muss gerechterweise sagen, das M$ wirklich nie versucht hat, MSAccess als (konkurrenzfähige/strategische) Datenbank weiterzuentwickeln.
War immer eher beiläufig mitgeliefert so nach dem Motto
Als professionelle Lösung für mehr als eine kleine Weinkellerverwaltung oder die Artikelverwaltung eines durchschnittlich erfolgreichen Salatbesteckversands wurde es nie gepusht.
@huefti
nachreichen wollte ich Dir noch zwei Ergänzungen
1) ein Beispiel für die (Re-)Produktion dieser "Kundenrechnungs-Lfdnr" mit einer halbstarken Abfrage
-- wobei die Tabelle bei mir huefti heißt und das künstlich berechnete Feld "KdLfdnr"
2) geht aus diesem Beispiel hervor, weshalb denn der PrimaryKey [hier Knd_Nr und Rech_Dat] wichtig ist.
Denn der ist ja gleichzeitig auch das "GROUP BY"-Kriterium
bzw. in meiner Formulierung der Abfrage die Gesamtheit der Feldinhalte, die in Detail- und Aggregatssicht der Tabelle übereinstimmen müssen
Grüße
Biber
okay, Deine Einschätzung bzgl. MSAccess ist nicht völlig unbegründet...
Aber (ja, manchmal nehme sogar ich diese Redmonder in Schutz) man/frau muss gerechterweise sagen, das M$ wirklich nie versucht hat, MSAccess als (konkurrenzfähige/strategische) Datenbank weiterzuentwickeln.
War immer eher beiläufig mitgeliefert so nach dem Motto
"optional hätten wir auch noch einen Datenbank-Dummy mit dem üblichen Design-Knöpfchen an den gewohnten Stellen und die Fenster lassen sich auch klein und groß ziehen und sieht eigentlich von der Oberfläche aus wie Excel. Und es spricht sogar ein paar Worte SQL!"
Als professionelle Lösung für mehr als eine kleine Weinkellerverwaltung oder die Artikelverwaltung eines durchschnittlich erfolgreichen Salatbesteckversands wurde es nie gepusht.
@huefti
nachreichen wollte ich Dir noch zwei Ergänzungen
1) ein Beispiel für die (Re-)Produktion dieser "Kundenrechnungs-Lfdnr" mit einer halbstarken Abfrage
SELECT h.Knd_Nr, h.Rech_Dat, h.Rech_Betr, hsub.kdlfdnr FROM (
SELECT h1.Knd_Nr, h1.Rech_Dat, h1.Rech_betr,
(SELECT count(h2.Rech_Dat) from huefti h2
WHERE h1.Knd_Nr=h2.Knd_Nr AND h2.Rech_Dat <= h1.Rech_Dat) as kdLfdnr
FROM Huefti h1
) AS hsub, huefti AS h
WHERE hsub.Knd_Nr = h.Knd_Nr
AND hsub.Rech_dat=h.Rech_dat
ORDER BY 1, 2;2) geht aus diesem Beispiel hervor, weshalb denn der PrimaryKey [hier Knd_Nr und Rech_Dat] wichtig ist.
Denn der ist ja gleichzeitig auch das "GROUP BY"-Kriterium
bzw. in meiner Formulierung der Abfrage die Gesamtheit der Feldinhalte, die in Detail- und Aggregatssicht der Tabelle übereinstimmen müssen
Grüße
Biber
Hallo Biber!
Ist zwar schon ne ganze Wile ins Land gegangen, aber ich hätte noch eine Frage zu deiner halbstarken Abfrage.
Welche Tabellen sprichst du mit h, h1 und h2 an?
Beste Grüße,
dasZonk
Ist zwar schon ne ganze Wile ins Land gegangen, aber ich hätte noch eine Frage zu deiner halbstarken Abfrage.
Welche Tabellen sprichst du mit h, h1 und h2 an?
Beste Grüße,
dasZonk
Moin dasZonk,
willkommen im Forum.
es gibt ja laut Beschreibung des Threaderstellers "huefti" nur eine einzige Tabelle, von der wir (Teil-)Kenntnisse haben.
Diese hat mindestens die Felder "Knd_Nr" mit Inhalt Kundennummer, "Rech_Dat" (Rechnungsdatum) und "Rech_Betr" ( Rechnungsbetrag).
Da ich nicht weiss, wie die beim Fragesteller heisst, habe ich sie gedanklich bzw denkfaul "huefti" genannt.
Ich hätte sie auch nach meiner Ex-Schwiegermutti nennen können, aber so raffiniert kam sie mir gar nicht vor. Die Tabelle mein ich.
Und diese 3-Felder-Tabelle spreche ich unter drei verschiedenen Aliasen an (als h, h1, h2).
Wobei mir der COUNT-Zugriff mit "from huefti h2" in Zeile03 eben eine "Laufende Kundennummer" generiert, die ich später als "hsub.kdlfdnr" anspreche.
Anmerkung: Um zu der Frage zurückzukommen, ob Access und Datenbanken gemeinsame Vorfahren hatten,..
--> In Access ist es meines Wissens nach NICHT mal möglich, innerhalb eines (noch so danach schreienden) SQL-Statements zu kommentieren.
Also Zeilenkommentare mit "-- " o.ä. zu hinterlegen. oder gar "/* comments */"
Ebenfalls aus meiner Sicht wäre das schon ein K.O.-Kriterium für den produktiven Einsatz dieses Tools.
Jedenfalls würde ich mit keinem anderen Datenbankblech so ein unwartbares Statement an der Qualitätssicherung vorbeischmuggeln können oder wollen.
Jedenfalls HÄTTE ich es kommentiert - ich weiss ja, dass es nicht intuitiv einleuchtend ist.
Grüße
Biber
willkommen im Forum.
es gibt ja laut Beschreibung des Threaderstellers "huefti" nur eine einzige Tabelle, von der wir (Teil-)Kenntnisse haben.
Diese hat mindestens die Felder "Knd_Nr" mit Inhalt Kundennummer, "Rech_Dat" (Rechnungsdatum) und "Rech_Betr" ( Rechnungsbetrag).
Da ich nicht weiss, wie die beim Fragesteller heisst, habe ich sie gedanklich bzw denkfaul "huefti" genannt.
Ich hätte sie auch nach meiner Ex-Schwiegermutti nennen können, aber so raffiniert kam sie mir gar nicht vor. Die Tabelle mein ich.
Und diese 3-Felder-Tabelle spreche ich unter drei verschiedenen Aliasen an (als h, h1, h2).
Wobei mir der COUNT-Zugriff mit "from huefti h2" in Zeile03 eben eine "Laufende Kundennummer" generiert, die ich später als "hsub.kdlfdnr" anspreche.
Anmerkung: Um zu der Frage zurückzukommen, ob Access und Datenbanken gemeinsame Vorfahren hatten,..
--> In Access ist es meines Wissens nach NICHT mal möglich, innerhalb eines (noch so danach schreienden) SQL-Statements zu kommentieren.
Also Zeilenkommentare mit "-- " o.ä. zu hinterlegen. oder gar "/* comments */"
Ebenfalls aus meiner Sicht wäre das schon ein K.O.-Kriterium für den produktiven Einsatz dieses Tools.
Jedenfalls würde ich mit keinem anderen Datenbankblech so ein unwartbares Statement an der Qualitätssicherung vorbeischmuggeln können oder wollen.
Jedenfalls HÄTTE ich es kommentiert - ich weiss ja, dass es nicht intuitiv einleuchtend ist.
Grüße
Biber
