SQL Eine Tabelle, ein Datensatz...Struktur?

[dreivier]

Hallo

Hab erst mit MySQL angefangen und auch schon ein kleines Problem.
Frage...

Wenn ich eine Tabelle habe in der nur ein Datensatz existiert und ständig verändert werden soll, wie müsste die Struktur aussehen? brauche ich da einen Autoindex also ID? ich glaube nicht oder?

Der Datensatz würde zb. so aussehen...

Name......Vorname......Alter......Herkunft......Land......Timestamp

Der Inhalt soll sich dann ständig ändern...

Merci...

 

[benneq]

Was genau meinst du mit "ein" Datensatz? Wirklich nur eine Zeile in der gesamten Tabelle? Also z.B. eine "User" Tabelle, aber es gibt nur einen einzigen User?

Im Grunde sind Datenbanken natürlich dafür konzipiert viele ähnliche (bzw. gleichartige) Inhalte pro Tabelle zu speichern, egal ob es MySQL, MongoDB oder sonst was ist.

In deinem Fall sieht es aus als wenn es eine Tabelle für Personen wäre. Aber wieso gibt es bei dir nur eine einzige Person?

 

[Donnidonis]

Wenn ich das richtig verstanden habe musst du doch lediglich ein UPDATE auf dein Benutzer machen.
So kannst du alle Attribute ändern und bleibst bei einem Datensatz.

 

[isiprimax]

Gibt da mehrere Lösungen dazu, wobei 1 Datensatz in der Tabelle kein Sinn ergibt, weil eine Datenbank eben für große Datenmengen ausgelegt ist.

Nach den Normalformen brauchst du einen eindeutigen Key (Primary Key), den kannst du über Auto Increment automatisch mitzählen lassen. Ist wohl das gänigste Verfahren. Man kann auch aus mehreren Spalten einen Primary Key erstellen, aber wie gesagt er muss eindeutig sein.

Wenn in deiner Where Klausel nur zb einen Namen eingibst wie zum Beispiel Tim, werden alle mit dem Namen Tim geändert.

Hab hier gute Seite zum SQL Lernen ( http://sqlzoo.net/de/ ).

 

[DanielBm]

Erkläre vielleicht erstmal allgemein deinen Anwendungsfall, dann kann man dir hier auch sagen, ob ein einziger Datensatz in einer Datenbanktabelle überhaupt Sinn macht, oder ob du deine Personendaten evtl. auch in anderer Form speichern könntest.

 

[SymA]

@isiprimax:
Wenn es wirklich so unsinnig wäre, gäbe es nicht solche Möglichkeiten wie UPDATE oder INSERT ... ON DUPLICATE KEY UPDATE

 

[Daaron]

UPDATE und INSERT ON DUPLICATE haben ihre Daseinsberechtigung in der Form, dass du evtl. eine Entity mit nem bestimmten PK hast, deren Werte sich ändern... oder du dir schlichtweg nicht sicher bist, ob diese Entity schon existiert und du sie hinzufügen/aktualisieren willst.
Eine Datenbank mit nur einer Row ist hingegen tatsächlich ziemlicher Quatsch.

Was die ursprüngliche Frage angeht: Aus Prinzip sollte immer ein Primary Key vergeben werden, und hier bietet sich ein Auto Increment einfach an. Nehmen wir mal das einführende Beispiel: Was willst du sonst als PK nehmen? Name+Vorname? Das geht ganz schnell nach hinten los.

 

[SymA]

@Daaron - klar eine Tabellen mit einem einzigen Eintrag ist absolut sinnfrei

 

[benneq]

UPDATE und INSERT ON DUPLICATE haben ihre Daseinsberechtigung in der Form, dass du evtl. eine Entity mit nem bestimmten PK hast, deren Werte sich ändern...

Für Auto-Increment (oder zufällig generierten) PKs (also surrogate keys) ist das in der Regel total sinnfrei, aber bei sog. natural keys kann das schon mal vorkommen.

Abgesehen davon könnte der TE natürlich auch die Daten für diesen einen Datensatz als Key-Value Paare in seiner Tabelle speichern, dann wären zumindest mehr als 1 Zeile drin

 

[Daaron]

Für Auto-Increment (oder zufällig generierten) PKs (also surrogate keys) ist das in der Regel total sinnfrei

Warum sollte UPDATE da nix bringen? INSERT ON DUPLICATE... klar. Aber UPDATE brauchst du immer. Oder hast du nie ein Produkt in einem Shopsystem aktualisiert?

 

[benneq]

Natürlich meinte ich nur INSERT ON DUP.

Mein erster Webshop steht erst in ein paar Monaten an, schon schlimm wenn der Kunde sich mit keinem erhältlichen Shop anfreunden kann. Da wird aber vermutlich auf MongoDB gesetzt. Soll mir aber Recht sein, für irgendwas muss man mich ja bezahlen

Bisher durfte ich mich nur mal mit xt:commerce rumschlagen - eigentlich sollte man eher die Entwickler dort mal schlagen für ihre JSON SOAP API.

 

[Daaron]

'cause it is webscale?
Was soll so ne dämliche NoSQL - Lösung bringen bei einer Problematik, die definitiv relational ist? Es gibt n Attribute (Farbe, Größe,...) mit m Werten. Es gibt x Produkte, die je in je einer Produktart sind. Jede Produktart bindet n Attribute ein. Jede Bestellung besteht aus n Produkten. Absolut relational.

Ich würd einfach sagen: Arschlecken, ich nehm Contao Isotope. Schnell, leichtgewichtig, mächtig, quelloffen, anpassungsfähig.

 

[benneq]

Ach, bei den 10000 Shop-Kunden im Monat, geht mir die Skalierung ziemlich am Popo vorbei. Ich find MongoDB einfach wesentlich bequemer zum Arbeiten Und das ist doch genau der Punkt. Ich könnte es auch in Text Dateien oder in einer Graphdatenbank umsetzen, funktionieren würde es überall, aber es geht schließlich um meine Effizienz und die ist dort eben deutlich höher.

Und ja, ich habe 15 Jahre Erfahrung mit RDBMS.

Btw: 1:n composition Relationen lassen sich in MongoDB deutlich schöner abbilden als in MySQL. Für m:n gilt das Gegenteil, aber das ist im Grunde so selten der Fall, dass ich die 3-4 Joins auch von Hand machen kann. Alternativ kann man natürlich auch auf Kosten der Datenintegrität die referenzierten Daten als Duplikate speichern. Freiheit ist manchmal schon ganz praktisch.
Und ich will darüber jetzt keine Diskussion anzetteln, ich hab genug Erfahrung damit und weiß was ich tue

Ist ja nicht so, dass der Herr Kunde nicht schon mit diversen Shops gearbeitet und keine Erfahrung hätte. Aber irgendwas passt immer nicht so hunderprozentig... Also kriegt er halt was er will.
"Arschlecken" sagen ist für mich nicht so praktisch, wenn der Auftrag dann an jemand anderen geht (auch wenn man das doch manchmal gern sagen würde)