Office: Primärschlüssel in jeder Tabelle zwingend?

Ich sehe doppelt, da ist Josef wieder *grins


Danke.

Werde ich mal beim Kaffee am Sonntag testen. Wobei ich stark bezweifel, dass sich das für eine DB mit 2500 Person Datensätzen und vielleicht 3000 Vertragsdatensätzen überhaupt lohnt... aber man fängt ja klein an.*tongue.gif*

 

\@Josef
Ich meinte auch des SQL Server Express respektive MSDE. Arbeitet denn Access 2000 auch mit der 2005 Express version zusammen oder nur mit der MSDE 2000?

 

Access ist die Version ziemlich egal. Sowohl SQL-2000 als auch SQL-2005-Tabellen werden tadellos eingebunden. (Und das ist hauptsächlich vom ODBC-Treiber abhängig.)
Nur bei ADP soll es Probleme mit dem Entwurfsmoduls geben. Finde ich aber sogar sehr gut, dass es dort Probleme gibt, damit entstehen nämlich bessere Anwendungen, da die Trennung zw. DB und FE klarer wird.
Ich selbst hielt und halte von ADP nicht sehr viel, Ich bevorzuge als FE immer noch eine mdb. (Da ich damals nicht auf diesen ADP-Zug aufsprang muss ich nun auch nicht wieder abspringen. *biggrin.gif*)
Außerdem bin ich dann nicht nur an den SQL-Server gebunden und kann meine Module/Formulare auch für andere DBMS einsetzen.

In der MDB verwende ich ich per ODBC verknüpfte Sichten als Datenbasis für Formular verwende bzw. binde die Formulare direkt an ein ADODB-Recordset.
Gespeicherte PT-Abfragen setze ich selten ein, da man deren enthalten SQL-Anweisung umstellen muss, um effizient Daten abzurufen (Where, OrderBy) - dann sind diese Abfragen aber nicht mehr instanzensicher.

 

Hallo nochmal,
ohne nun auf die einzelnen Komentare eingehen zu können.
Aus Datenbank-TECHNISCHER Sicht habe ich durch die Beiträge einiges an Wissen dazugewonnen. Dafür Dank an alle Beteiligten. *hands

Die Vorteile von Surrogaten Keys waren ja wie erwähnt schon in Atrus´ Link in #7 aufgezeigt und ich werde bei den nächsten Projekten das neu erworbene Wissen berücksichtigen. *holy

Bezüglich der Hilfestellung hier im Forum habe ich meine Meinung jedoch nicht geändert, *nene denn ich erinnere mich noch gut, wie ich selbst als Fachfremder mit den ersten Datenbanken begonnen habe. Mich jedenfalls hätte damals eine solche Beitragsflut (Stichwort Clustered Index eines SQL-Servers) total überfordert.

Daher stelle ich mal eine bewusst provokante Frage: Wer von euch hat seine erste, zweite oder auch dritte eigene Datenbank mit Surrogat-PKs ausgestattet? ;-)

Versuche mich gerade (gaaaanz langsam) mit dem Umstieg auf andere DBMS zu beschäftigen, soweit die Zeit reicht. Schon die Frage in welches System man sich nun einarbeiten sollte, ist durch einfaches googlen nicht zu lösen da es scheints erhebliche Unterschieden bezüglich der Leistungsfähigkeit, Datensicherungsmöglichkeiten ... gibt.
Diese Unübersichlichkeit jedenfalls scheint für mich auch ein Grund zu sein, warum viele, trotz alller eingeredeten und realen Nachteile bei MDB und MDE kleben bleiben.
Das einzige was ich wirklich vermisse ist ein akzeptables, wenn möglcih integriertes, System der Datensicherung! *bawling

Sascha, wenn du mitziehst werden wir uns wohl bald viel zu erzählen haben ... oder löchern weiter Josef *wink.gif*

 

Mal eine provokante Frage: hast du schon mal mit bsp. einem SQL Server ernsthaft gearbeitet? Wenn dem so ist wundert mich deine Aussage nur die Datensicherung in Access zu vermissen. Aber offenbar habe ich da einen anderen anspruch bzw Erwartungen an eine DB, die sicherlich auch von dem Verwendungszweck dieser abhängen. Wenn dir access reicht ist dass toll und ein Umstieg lohnt nicht . Dennoch sollte man sich einmal mit den vorzügen echter datenbankserver und deren DBMS beschaftigen.Diese Entscheidung hast du ja bereits für dich getroffen und wahrscheinlich nicht nur wegen der fehlenden Sicherung der DB! Und hätte mir jemand in anfangszeiten etwas von einem surrogate key erzählt wäre ich glücklich gewesen etwas fundamentales gelernt zu haben und hätte dann zumindest diesen Fehler vermeiden können.

 

OT:
@torsten
Nein! Kommt aber noch *Smilie Und ich würde mich freuen, auf die dann haufenweise auftretenden neuen Fragen zu Stored Procedures, Trigger usw... fundierte Antworten von dir zu bekommen *wink.gif*
Danke im vorraus

 

Zum Thema Anfänger:

Ich vermute, dass die meisten Einsteiger in Access sich an der Nordwind abgearbeitet haben (Josef, hör mal weg *Smilie ). Und da gibt es ein wunderbares Beispiel für die Unsinnigkeit "realer" Schlüssel: der Kundencode in der Kundentabelle.

Der Wert "ALFKI", der dort für den Kunden "Alfreds Futterkiste" steht, ist ja nicht ein künstlicher, unabhängiger Schlüssel, sondern eine (mehr oder minder schöne) Abkürzung für den Firmennamen. Wenn sich jetzt Alfreds Futterkiste in Alfreds Schnuckelstube umbenennt, ist ALFKI dafür eine ziemlich blöde Abkürzung. Also wird ALFKI in ALSCH geändert. Und schon "muss" man einen Schlüssel ändern, weil irgendwas Reales passiert ist. Eigentlich ist es ja derselbe Kunde, es hängt nur ein anderes Schild an der Tür.

Klar, die Weitergaben können das nachziehen. Aber im Prinzip ist das alles völlig unnötig.

Und da ich ein fauler Hund bin, ist alles, was unnötig ist, von Übel :-)

 

Hmmm, naja, aber wenn man etwas neues anfängt ist das in der Regel immer so. Sprache, Weiterbildung, egal was. Am Anfang stehst vor einer Wand und musst erstmal die Kletterausrüstung sortieren. *wink.gif*

Anfägnlich hatte ich fast alles über die natürlichen Keys gelöst, mit den Jahren machten diese immer mehr Probleme, je grösser das Projekt wurde, deste störender waren diese.

Ich denke die Systemfrage ist beim Einsatz von Access recht schnell geklärt. Da würde ich persönlich auf das Produkt aus dem selben Hause zurückgreifen. Das ist mit Sicherheit am besten Unterstützt und bietet die wenigsten Fallstricke.

Das ist in Access aber easy, Copy-Paste der Backend. Oder auch per Task. Hallt ohne Rollbacks und dergleichen.
Aktive Db-Systeme haben ne Menge Vorteile. Ich nenne mal so ein paar schlagkräftige:

Wenn du nur schon an die vorhin angeführte Kunden/AufträgeErfassung von externen Mitarbeiter ohne direkte Online-Anbindung denkst. Ein Atkives System kann, sobald du die Datensätze in die Datenbank einfügst, ein natürliches Geschäftsfeld nach deinem Formatierungswunsch mit einer laufenden Nummer füttern, falls diese erwünscht sind. Zbsp. für Chargen-Nummern nötig. Werden diese in der Frontend generiert und nicht im absolut gleichen moment gespeichert, könnte es sein, dass durhc einen anderen User die gleiche Nummer erstellt wird.

Ein anderes Beispiel: Du machst auswertungen von Umsätzen, wenn du für sämtliche Auswertungen immer alle Rechnungsposition zusammenzählen musst, Prozentsätze abziehen, Rabatte berücksichtigen etc. dann ist das eine ziemliche Tortur für das System. Ist nun aber der Gesamtbetrag innerhalb des Auftrags quasi redundant abgelegt, brauchst du keinerlei Joins. In Access ist das unterfangen etwas heikel, da musst du selber programmtechnisch sicherstellen, damit dieser Betrag immer stimmt. Natürlich möglich solange du immer nach Schema F deine Daten änderst oder über Klassen gehst, welche das ganze für dich zuverlässig erledigen. Heikel bleibt es trotzdem, eine andere Frontend, direkte Bearbeitung in der Backend etc. kann das System schnell zu Fall bringen.
Ganz anders bei aktiven Datenbanksystemen. Hier hast du die Möglichkeit Felder aufgrund von Kritieren automatisch berechnen zu lassen, sobald Detailsätze hinzugefügt, geändert, gelöscht, storniert werden. Dadurch kannst du in Auswertungen enorme Performancegewinne erhalten bei grossen wie manchmal auch schon bei kleinen Projekte, weil einfach nur ein Feld ausgelesen werden muss ohne viele Joins und summierungen etc.

Auch bei der Datensicherheit sieht es ganz anders aus. In Access kann jeder deine MDB kopieren und mit nach hause nehmen. Ziemlich mühsam oder? In einem Einmann-Betrieb nicht weiter schlimm, aber bei vielen Mitarbeiter wird das zu einem Risiko. Auch kann jeder die Backend mit irgendwas überschreiben. Im Aktiven System hat der User keinen direkten Zugriff auf die Datenbankdateien sondern geht in der Regel über einen Dienst, an welchem du dich erst authentifizieren musst, in die Datenbank rein. So kannst du sehr gut steuern, was jeder machen darf. So kannst du beispielsweise die Zugangsdaten im SourceCode ablegen. Ohne Deine Software kommt also kein einziger in die DB rein wenn du das nicht möchtest.