Wie zusammengesetzte CaseID in Datenbank speichern

[urmel]

Hallo liebe Gemeinde,

in meiner Tabelle "bookings" soll eine CaseID gespeichert werden. Diese hat folgende Struktur: YYYY/MM/nnnn (nnnn=4stellige autoincrement number >1000).

Folgendes Szenario liegt zu Grunde:
Ein Datensatz wird entweder 'durch einen Kunden' generiert: ausfuellen eines Buchungsformulars auf der Webseite oder durch einen Mitarbeiter (zB wenn eine Buchungsanfrage per email eintrifft), ebenfalls durch ausfuellen eines Buchungsformulars. Die CaseID soll in beiden Faellen automatisch generiert werden.

z.B. eine Buchung die im Maerz 2010 erstellt wird hat CaseID 2010/03/1001

Zu meinen Fragen:
1. Zu welchem Zeitpunkt generiere ich die CaseID - nach submit des Formulars via PHP und dann als Ganzes in die Tabelle schreiben?

2. Ist es guenstiger 2010 03 nnnn in drei Spalten zu speichern an stattt in einer?

Sorry meine Fragen, ich habe seit 5 Jahren nicht mehr mit PHP und mySQL gearbeitet... der Mensch ist einfach zu vergesslich

Vielen Dank!

[urvater]

Zu meinen Fragen:
1. Zu welchem Zeitpunkt generiere ich die CaseID - nach submit des Formulars via PHP und dann als Ganzes in die Tabelle schreiben?

2. Ist es guenstiger 2010 03 nnnn in drei Spalten zu speichern an stattt in einer?

1. wird nicht funktionieren. Du müsstest ja den letzten Wert aus der DB holen, per PHP um 1 erhöhen und in die DB speichern. Was passiert, wenn ein oder mehrere User eine Bestellung im Web aufgeben und 2-3 Bearbeiter intern zu gleichen Zeit auf SUBMIT drücken?.

2. ist wesentlich besser. Zum einen würden sich so auch leichter Statistiken etc. bewerkstelligen lassen.
Zum auto_increment solltest du dich mal hier auf MySql belesen. Besonders das 2. Beispiel dort sollte deinem Vorhaben entsprechen.

[urmel]

Zitat von urvater

1. wird nicht funktionieren. Du müsstest ja den letzten Wert aus der DB holen, per PHP um 1 erhöhen und in die DB speichern. Was passiert, wenn ein oder mehrere User eine Bestellung im Web aufgeben und 2-3 Bearbeiter intern zu gleichen Zeit auf SUBMIT drücken?.

-> stimmt, habe ich nicht bedacht

Zitat von urvater

2. ist wesentlich besser. Zum einen würden sich so auch leichter Statistiken etc. bewerkstelligen lassen.
Zum auto_increment solltest du dich mal hier auf MySql belesen. Besonders das 2. Beispiel dort sollte deinem Vorhaben entsprechen.

-> danke fuer den Link, passt super

Noch eine Frage: Lege ich zusaetzlich einen kuenstlichen Primaerschluessel fest. Ich habe eine Tabelle "BookingDetails", welche zu "Bookings" referenziert. Andernfalls muesste ich die dreispaltige Struktur Year Month Serial wieder aufnehmen, oder?

[urvater]

Ich würde den gleichen Primärschlüssel nutzen, wei du ihn bei den Buchungen selbst nutzt. Du benötigst ja einen eindeutigen Schlüssel um eine Verbindung zu beiden Tabellen zu erhalten. Wozu noch einen weiteren Schlüssel nutzen?

[urmel]

Entschuldige, ich habe mich falsch ausgedrückt: In der Tabelle 'Bookings' bilden die Spalten 'year' 'month' 'serialno' einen zusammengesetzten Primärschlüssel. Ist es hier nicht sinnvoll an statt des zusammengesetzen Primäschlüssels einen einfachen PK über eine zusätzliche Spalte 'ID' zu bilden?

So muesste ich in der Tabelle 'BookingDetails' nur einen Fremdschlüssel 'BookingsID' anlegen, statt 'bookings.year' 'bookings.month' und 'bookings.serialno'. Was ist geängige Praxis?

[urvater]

Keine Ahnung was hier die gängige Praxis ist, da hier die Kunden- oder eigenen Wünsche unterschiedlich sein können.

So muesste ich in der Tabelle 'BookingDetails' nur einen Fremdschlüssel 'BookingsID' anlegen, statt 'bookings.year' 'bookings.month' und 'bookings.serialno'. Was ist geängige Praxis?

Dafür müsste die Tabelle 'Bocking' eine zusätzliche Spalte 'BookingsID' bekommen, da du sonst keinen Bezug zwischen den Daten hast.

Oder wie willst du dir die Buchungsdetails zu einer Buchung ausgeben lassen?

[urmel]

Zitat von urvater

Dafür müsste die Tabelle 'Bocking' eine zusätzliche Spalte 'BookingsID' bekommen, da du sonst keinen Bezug zwischen den Daten hast.

-> genau darauf zielt meine Frage ab

Zitat von urvater

Oder wie willst du dir die Buchungsdetails zu einer Buchung ausgeben lassen?

-> genau das ist mein Ziel. Eine Buchung von Kundem A umfasst die Leistungen X, Y und Z. Die Buchung (Kundenr., Buchungsdatum etc.) moechte ich in der Tabelle 'Bookings' speichern. Die gebuchten Leistungen X, Y und Z in der Tabelle 'bookingDetails'. Spaeter soll es moeglich sein die Leistungen aus der Tabelle 'bookingDetails' wieder der Buchung in Tabelle 'Bookings' zuzuordnen.

Z.B Kunde A hat am 20.04.2010 die Leistungen X, Y und Z gebucht.

Daher dachte ich dass es vielleicht besser ist nicht 'yyyy mm nnnn' als Schluessel zu verwenden, sondern zusaetzlich eine DB-interne "BookingsID" einzusetzen.

[urvater]

Mal zur Veranschaulichung der Tabelle bookingDetails

|Jahr|Monat|auto_increment|Leistungsschlüssel|kundenID|eventuell andere Buchungsrelevante Details

Jahr, Monat und auto_increment kommen aus der Buchung selbst.
Buchungsschlüssel wäre ein Schlüssel über die gebuchte Leistung.
Du könntest den Index über alle 4 Spalten setzen und hättest somit einen eindeutigen Index.
Eine Leistung kann ja nur einmal in einer Buchung vorkommen allerdings mit XY Stück, wenn es sich um Produkte handelt.

PS: Leistungsschlüssel könnte auch eine Produkt-Nr. oder ähnliches sein.

Somit wären zahlreiche Abfragemöglichkeiten möglich.
Welche Buchungen gehören zu Buchung XYZ?
Welche bzw. wieviele Buchungen hatte Kunde XY im Jahr AD?

Oft sehr interessant
Wie oft wurde die Leistung CD im letzten Quartal, Monat oder Jahr gebucht?

Eine zusätzliche ID könntest du speichern ist aber generell nicht notwendig.