Feld darf nur einmal vorkommen

[Hansa]

Ähh, hmmm,

also mit access und co. will ich nix zu tun haben. Ich muß kein Telefonverzeichnis proggen, sondern eine relationale DB, ungefähr 50-100 Tables). Und das hängt alles miteinander zusammen. Die DB soll auch auf einem Linux-Server liegen können. und und ...

Die Frage läuft im Moment darauf hinaus, wo hin der Primary Key soll.

[Sharky]

Zitat von Hansa:

...also mit access und co. will ich nix zu tun haben.

Das sagt ja auch keiner.

Zitat von Hansa:

... Ich muß kein Telefonverzeichnis proggen, sondern eine relationale DB,

Ich glaube kaum das DU ein Datenbanksystem programmiers

Zitat von Hansa:

...Die DB soll auch auf einem Linux-Server liegen können. und und....

Wo die liegt ist doch nicht wichtig.

Und und und..... Was soll jemand damit anfangen?
Akzeptiere doch einfach mal das Du einen grundsätzlichen Fehler in der Planung deiner DB hast.
Danach kannst Du so tun als würdest Du wissen um was es geht.

Sorry für meine harten Worte. Aber in der letzen Zeit lese ich von Dir immer mehr Beiträge in der obigen Art.

[Hansa]

Zitat:

Ich glaube kaum das DU ein Datenbanksystem programmiers

Wo die liegt ist doch nicht wichtig.

Und und und..... Was soll jemand damit anfangen?
Akzeptiere doch einfach mal das Du einen grundsätzlichen Fehler in der Planung deiner DB hast.
Danach kannst Du so tun als würdest Du wissen um was es geht.

Sorry für meine harten Worte. Aber in der letzen Zeit lese ich von Dir immer mehr Beiträge in der obigen Art.

Wenn Du meinst. 8) Antwort kam bislang jedenfalls keine. Na gut, dann frage ich eben erst gar nicht mehr weiter.

[Leuselator]

Hey Hansa alter Junge nicht gleich einschnappen, wenn der Hai mal zuschnappt!

Allerdings ist etwas daran: Du mußt 'ne Entscheidung treffen:
1. Du schränkst die möglichen Zieldatenbanken auf ausgewachsene DB's (also solche mit StoredProcedures, Trigger, Constraints etc.) ein (btw. gibt es DB2 von IBM, welches durchaus ein ausgewachsenes DBMS ist auch für Linux) und verkleinerst dadurch Deinen möglichen Markt, kannst aber andererseits auch systematisch vernünftige Ansätze verwirklichen.
Oder
2. Du verzichtest auf die Weitergehenden Möglichkeiten ausgewachsener DBMS's, vergößerst Deinen Markt und "frickelst" es irgendwie zurecht.

Es gibt immer Argumente für die eine und die Andere Seite - soll hier nicht das Thema sein.

Richtig ist es auf jeden Fall, die Business-Logik strikt von der DatenbankStruktur- und Integrität zu trennen: Morgen schießt Deinem Kunden ein Furz aus dem Darm mit dem Umweg über's Rückenmark ins Hirn und Du wirst beauftragt, die Kundennummern um den Tag des Geburtsdatums zu erweitern - was dann (kein Scherz - habe solche und noch viel krudere Nummern erlebt)? Dann hängt Deine Datenbank womöglich komplett an den alten Kundennummern, da Du diese als Primary verwendet hast - viel Spaß damit!

Deshalb denk doch nochmal ernsthaft über eine Auslagerung der Kundennummer in eine separate Lookuptabelle nach, und benutze ansonsten konsequent servergenerierte ID's als Primary Keys in Deinen Tabellen. Wenn dann eine Änderung der Businesslogik in Bezug auf die Kundennummern stattfindet, kannst Du die ohne Kummer in Deiner DB nachvollziehen.

In meinem aktuellen Projekt habe ich eine DB mit ca. 160 Tabellen und insgesamt etwa 30 Mio Datensätzen. All diese Tabellen referenzieren am Ende mehr oder weniger direkt eine zentrale Entitätstabelle, die aus 6 Spalten besteht: Id,Typ,DatumStart,DatumStop,IdErzeuger,IdLöscher. Egal, wie sich die Hülle (Atribute) der Entitäten in Zukunft ändert - ich werde immer wieder einen EinEinDeutigen Zugriff auf die Entität haben - eine wirkliche Beruhigung!

Also schnapp wieder aus, und benutze den Hammer zum nageln und die Säge zum sägen
(Ich arbeite schließlich auch ab jetzt mit der Objektablage!)

Gruß

PS: die Protagonisten der "Select max(Id)"-Methode sollten sich mal fragen, wie sicher diese Variante im Mehrbenutzerbetrieb ist, wenn 2 Leute gleichzeitig einen neuen Kunden anlegen wollen, aber leicht zeitlich versetzt posten. Die Katastrophe ist dann vorprogrammiert. Solche sachen gehören nunmal in die Kompetenz der DB und nicht in die der Clients.

[kiar]

Dem ist nicht's hinzu zufügen

ein schlechtes DB Design wird sich später immer rächen.

raik

@Hansa, denke an das Tut mit der Objektanlage, wenn du mal wieder hier bist

[Hansa]

Habe mich jetzt strikt an die Theorie gehalten. DIe IDs erhalten bzw. behalten den Primary Key. Siehe Leuselators Post. Den PK lege ich nicht auf eine Nr., wie Robert_G vorgeschlagen hat. Ansonsten habe ich die uniques so gemacht wie von DelphiDeveloper vorgeschlagen.

Der Haken an der Sache war lediglich ein nicht vorhandenes Feature in IBExpert. Normalerweise werden die Identifier automatisch vergeben. Manchmal aber auch doppelt. Das fiel mir anfangs nicht auf.