Grundlegendes Datenbankdesign

[af0815]

Ja, ja, Andi, das gute alte CP/M. Stell Dir mal vor, unter einem Schneider cpc 6128 hatte ich noch dbase II unter CP/M laufen.

OFFTOPIC:
Die war nicht gut, viel zulange zur Pension und wenig Verdient bei viel Arbeit Das letztere hat sich nur wenig geändert

ONTOPIC:
Bezüglich Mandanten, einfach nur gegen eine Mandantentabelle joinen als Lösung oder mehr ?!
Wenn das Thema umfangreicher wird, sollten wir es in einen anderen Thread verlegen !

[pluto]

Ich habe angefangen mit ID'S zu arbeiten. Diese ID'S werden zufällig erzeugt und können Zufällig lang sein.

Das heißt jede Eintrag in die Root Tabelle bekommt eine ID. Zu dieser ID kann es jetzt noch weitere Tabellen geben.
z.b. wann wurde das Letzte Mal drauf zugeirefen ? wann wurde der Eintrag zum letzten mal geändert.

Das sind alles Bases Daten die zu einem Eintrag(ID) dazugehören.

Außer Dem könnten es noch weitere Tabellen mit Daten zu einem Eintrag geben. z.b. Ein Text/eine Link Liste kann zugeordnet werden.

So ein System versuche ich gerade zu machen. Im Moment kann ich nur ein Baum nach diesem Prinzip speichern und laden(stückenweise).

[Christian]

...und können Zufällig lang sein.

hm ?
geil wollte schon immer mal den ganzen hauptspeicher voll "id" haben

[pluto]

naja sie haben eine maximale. länge von z.b. 10 Stellen oder so...

[monta]

? und was fürn Datenbereich soll das sein? Integer oder einfach Char, und ganz zufällig ist wohl auch nicht war, es sollten wohl keine zwei gleichen GUIDs auftreten

[Christian]

Und wozu, und was hat das mit dem Thread hier zu tun ?

[pluto]

ich weiß nicht was du wieder hast. Hier geht es doch um grundlegende Fragen, und das ist eine Grundlegende Frage zum Thema "Daten Banken".

Die ID sind Integer es ist unwahrscheinlich das es zwei gleiche gibt !

Wenn die DB größer wird, könnte ich ja einfach eine Funktion rein tuen, die dann weiter sucht.. bzw. erst schaut ob es schon eine ID mit diesem Name gibt.

Ich finde die Idee mit den ID'S nicht schlecht. So währe es auch einfacher ein Adressen Verwalter zu schreiben: jeder neue Eintrag hat eine ID und zu diesen ID fallen Daten an.
diese Daten könnten zusammen gefasst werden.

Eine Suchfunktion stellt nun fest welche Daten es zu diesen Eintrag gibt. und Fertig.
So kann sich der Name ändern, oder der Name kann Sonderzeichen enthalten, dürfte alles keine Rolle Spielen. Oder übersehe ich jetzt was ?

Und später können weitere Tabellen zu einem Eintrag angelegt werden.
Wenn es aufgebaut ist !!!

[monta]

Pluto...was du hier erfindest ist mit verlaub eine der einfachsten Datenbankgrundlagen die es überhaupt gibt. Ne Datenbank ohne Candidate Keys wovon einer als Primärschlüssel agiert wirds bei ner guten Datenbank nie geben.
Lies mal Codd . Nein im ernst, schau dir mal die Einführung in der WissensDB an, Schlüssel sind da auch erwähnt.

Ich werd nächste Woche auch mal was reinstellen, wo die Beziehungen ausfürhlicher erklärt sind.
Und IDs aus Zahlen zufällig zu erstellen ist auch Mist, zähl doch einfach hoch. Schon die Möglichkeit zweier gleicher Primärschlüssel darf nicht bestehen wenn du ne relationale DB machen willst, und darauf läuft deine Ausführung drauf hin.

[af0815]

Und IDs aus Zahlen zufällig zu erstellen ist auch Mist, zähl doch einfach hoch. Schon die Möglichkeit zweier gleicher Primärschlüssel darf nicht bestehen wenn du ne relationale DB machen willst, und darauf läuft deine Ausführung drauf hin.

Die Idee selbst ist nicht schlecht und hat durchaus eine gute Berechtigung. Über die Methode der Erstellung der Zahlen kann man diskutieren. Normalerweise nimmt man GUIDs.

Warum eindeutige IDs und nicht Autoincs. Dann wenn du verschieden Tebellen replizieren und abgleichen musst, zwischen Standorten mit eigenen Servern, sind Autoincs of der Tod bzw. bedeuten viel mehr arbeit. GUID sind hier nicht nur Tabelleneindeutig sondern global Eindeutig und somit IMMER identifizierbar. Auch bei gleichen Tabellen auf verschiedenen Servern.

[pluto]

Monta, wenn ich hochzähle muss ich aber praktische alle Items prüfen, es kann ja sein, das ich zwischendurch welche gelöscht habe.... in der Tabelle.....
aber GUIDs. sind doch zufällige id oder nicht ? nur halt länger...

[af0815]

Monta, wenn ich hochzähle muss ich aber praktische alle Items prüfen, es kann ja sein, das ich zwischendurch welche gelöscht habe.... in der Tabelle.....

Die gelöschten = Lücken betrachtet man normalerweise nicht, sondern verwendet immer die nächste freie oder vom Generator (Autoinc) erzeugte. Bei den meisten Anwendungen kann man die Lücken vergessen und bei GUIDs darfst du an sowas nicht mal denken.

[pluto]

Aber wenn ich die Lücke auslasse was nützt mir dann die ID ?
wenn ich sie z.b. im Programm für irgendwas Brauche....

Du meinst es ist nur wichtig die Anzahl zu wissen um die ID zu erzeugen...
auch keine schlechte Idee....

[af0815]

Aber wenn ich die Lücke auslasse was nützt mir dann die ID ?
wenn ich sie z.b. im Programm für irgendwas Brauche....

Du meinst es ist nur wichtig die Anzahl zu wissen um die ID zu erzeugen...
auch keine schlechte Idee....

Nimm die ID nur als Kennzeichen für die Eindeutigkeit, nicht für andere Sachen. Denn spätestens bei der Verwendung der GUID gibt es das Thema lücke nicht.

Aus der Anzahl eine ID zu erzeugen ist auch keine gute Idee. Überlass es den Generatoren. Die können das absolut eindeutig erzeugen.

[monta]

ja, wie af schon sagt, Lücken sind völlig egal.

Vorteil ist die einfache Erzeugung bei absoluter Eindeutigkeit innerhalb der Relation.

Über das für und wieder von GUID vs. ID kann man natürlich streiten. Auf jeden Fall gibts auch deutliche Performanceunterschiede, die Integer-ID läuft beispielsweise bei FB gut doppelt so schnell beim Select wie mit GUID.

siehe 8: HK Software, IBExpert Database Performance Newsletter, 13. Februar 2007

[pluto]

Warum gleich zweimal das gleiche ?
Danke für den Tipp mit den ID.... eigentlich ist das keine schlechte Idee.
Mal sehen ob ich das bei mir noch einbauen werde/kann....