✔ INSERT + Aktueller Index

[Scotty86]

Hallo,
ich schreibe momentan an einen PHP Seite, die mit einer mySQL-DB hinterlegt ist.
In einen Script fuege ich einen Datensatz in eine Tabelle ein.


Vereinfacht sagen wir die Tabelle hat 3 Spalten. ID die automatisch hochzaehlt, eine Feld Name, das nicht Unique ist/sein darf und ein Feld Passwort. Es kann also ein Name 2mal in der Tabelle vorkommen. Zu jeder Zeile in der Tabelle wird eine weitere Tabelle mit dem Namen ID_Daten erstellt. Somit kann ich jedem Namen seine eindeutigen Daten zuweisen.
Nun brauch ich aber gleich beim Insert-Befehl die rueckgabe der ID, da auch 2 oder mehr Namen eingetragen werden koennen. Befehle wie LAST_INSERT_ID kann ich somit nicht verwenden, da die Gefahr besteht, dass zwischen Schreibe- und Lesevorgang des einen Scripts ein Schreibzugriff eines anderen Scripts ausgefuehrt wird, und somit das DB-Konstrukt Fehlerhaft wird.

(Es handelt sich hierbei nicht um ein Login, ich hab es lediglich als vereinfachtes Beispiel ausgesucht)

Hat jemand eine Idee/Loesung. Ich koennte einen Hash oder aehnliches aus allen Daten bilden und mit ihm die Datensaetze differenzieren, doch finde ich das unschoen.

Gruesse
Scotty86

 

[shutdown]

Ich würde dir dringend raten, dein Datenmodell zu überarbeiten.
Für jeden User eine eigene Tabelle anzulegen, ist nicht nur äußerst unschön, es frisst auch einiges an Ressourcen und ist zudem vollkommen überflüssig.

Die Art der Daten wird für jeden Benutzer ja gleich sein ==> alles in eine Tabelle.
Über die Normalformen extrahierst du aus dieser Tabelle Schlüsseltabellen und Nebentabellen. Und schon hast du bei 10000 Usern trotzdem nur eine handvoll Tabellen.

 

[Scotty86]

Ich habe ja gesagt es ist nur ein Beispiel um es auf eine simpelste Ebene zu bringen. Die Tabellen die dann erstellt werden sind nicht identisch und es muss auch jede Tabelle individuell geaendert werden koennen, da das System flexibel bleiben muss.

 

[Sven Mintel]

Nun brauch ich aber gleich beim Insert-Befehl die rueckgabe der ID, da auch 2 oder mehr Namen eingetragen werden koennen. Befehle wie LAST_INSERT_ID kann ich somit nicht verwenden, da die Gefahr besteht, dass zwischen Schreibe- und Lesevorgang des einen Scripts ein Schreibzugriff eines anderen Scripts ausgefuehrt wird, und somit das DB-Konstrukt Fehlerhaft wird.

LAST_INSERT_ID() wird nicht durch andere Skripte beeinflusst, das gibt dir die letzte von deinem Skript(deiner Verbindung) erzeugte ID zurück.

Ansonsten: du kannst Tabellen auch für die Zeit deines Zugriffs sperren.

 

[shutdown]

Selbst wenn die Tabellen nicht identisch sein sollten.
Man kann das im extremsten Fall auf die Zuordnung von key/Value-Paaren runterbrechen.
Dann gibt es eine Tabelle mit drei Spalten: Id, key, value.

Key wiederum ist in eine Schlüsseltabelle ausgelagert, value kann, muss aber nicht, ebenfalls ausgelagert sein. Über dei ID stellst du eine Referenz zur Usertabelle her.

Fertig. Ca. 5 Tabellen und es ist jede Kombination an Tabellen/Zuordnungen, die du im Kopf hast, möglich.

Erst Datenbankdesign, dann Programmierung.

 

[Scotty86]

@Sven Mintel:
Danke!

@shutdown:
Wenn der Kunde es so in seiner kleiner Welt will, dann mach ich es ihm so.

 

[dbwizard]

Selbst wenn die Tabellen nicht identisch sein sollten.
Man kann das im extremsten Fall auf die Zuordnung von key/Value-Paaren runterbrechen.
Dann gibt es eine Tabelle mit drei Spalten: Id, key, value.

Key wiederum ist in eine Schlüsseltabelle ausgelagert, value kann, muss aber nicht, ebenfalls ausgelagert sein. Über dei ID stellst du eine Referenz zur Usertabelle her.

Fertig. Ca. 5 Tabellen und es ist jede Kombination an Tabellen/Zuordnungen, die du im Kopf hast, möglich.

Erst Datenbankdesign, dann Programmierung.

@shutdown : Das ist exakt dasjenige "Datenbankdesign", welches ich schon öfter mal in Real- World Projekten angetroffen haben und die sich, wenn es sich nicht gerade um eine Miniapplikation handelt, in der Regel als (Verzeihung) "absoluter Schrott" herausgestellt haben

 

[shutdown]

Das kommt ganz auf den Anwendungszweck an - über den wir in diesem Fall immer noch nicht wirklich was wissen.

Je komplexer das ganze wird, desto mehr Redundanz wird man natürlich einbauen. Nicht zur Datensicherheit, sondern einfach schon aus Performance-Gründen.

Davon abgesehen hängt das auch immer ein wenig von der aufnehmenden Applikation ab. Eine PHP-Applikation, die durch den Server evtl. nur 30 Sek. laufen darf, ist was anderes, als ein komplettes Java-Frontend.

Ich will jetzt keinen Glaubenskrieg anzetteln, aber die Normalformen haben ihren Sinn. Und für jeden User eine Tabelle anzulegen, tut meinem Informatikerherz einfach ganz furchtbar furchtbar weh.

 

[dbwizard]

Und für jeden User eine Tabelle anzulegen, tut meinem Informatikerherz einfach ganz furchtbar furchtbar weh.

- Ja, mir auch. Mein Aussage war vielleicht etwas harsch formuliert, aber solche "DB-unabhängingen", oder "Vollständig Parameterisierbaren" Systeme machen mich einfach immer furchtbar nervös


Gruss

 

[Scotty86]

@shutdown:
das naechste mal schlaf ich ne Nacht drueber bis ich ein Beispiel auswaehle. In der Datenbank weden im Schnitt 5-6 Tabellen existieren, wovon eine statisch ist und bestehen bleibt, somit dem Kunden als Basis und Uebersicht dient, alle anderen werden dynamisch von einen Script nach Wunsch erstellt und geloescht. Fuer ein solches Projekt ist ein dieses Konzept in Handhabung und Geschwindigkeit effizienter. Ein Fall, dass Bezeichner doppelt vorkommen wird es dabei wohl auch nicht geben, aber ich als Informatiker gehe vom DAU + WorstCase aus.

Und fuer die Zukunft erstmal aufs Problem eingehen, bevor man es in Frage stellt, oft hat der Kunde keine Ahnung von Informatik, aber dafuer um so mehr von seiner kleinen Welt.