Hi Klaus,
- Es wäre durchaus auch möglich, daß Rechner mehrere IP-Adressen haben, bzw. in mehreren Netzwerken vorhanden sind. Auch hier wäre eine Auslagerung der IP-Adressen sinnvoll
Hm, ok.
- Es kann durchaus auch sein, daß ein Kunde in seinen Netzwerken für verwschienden Anwender verschieden POP3- und SMTP-Server verwendet. Das ist in Deinem Modell nicht abdeckbar. Abgesehen davon, müßten ja Dienste wie DNS, Gateway, Proxy usw. von Rechnern erledigt werden, die auch in dieser Datenbank stehen müßten. So gesehen könnte hier eine Referenz auf die entsprechenden Rechner erfolgen, auch auf die Gefahr hin, Zirkelbezüge zu erstellen
das habe ich jetzt nicht ganz verstanden :/
- die Software würde ich auch eigene Tabellen lösen. Es könnte auch durchaus sinnvoll sien, zwei Tabellen für die Software ansich und deren Versionen zu verwenden, also eine in der beispielswiese Word, Acrobat Reader, Delphi, Windows NT usw. abgebildet sind und in einer zweiten, in der dann die möglcihen Versionen (Word 95, 97, 2000 usw) verwaltet werden. Für jeden Rechner wird dann aufgenommen, welche Version der Software nun wirklich daruaf läuft. BTW. Du siehst, eigentlich habe ich das OS zu nebenbei auch zur Software gemacht.
Ja weil OS ist ja Software, da hast du auch Recht. Also eine Auslagerung auf 2 Tabellen wäre wirklich sinnvoll in dem Moment. Ok.
- Für die Hardwareausstattung könnte es durchaus auch sinnvoll sein, daß man diese über zusätzlcihe Tabellen verwaltet.
Versteh ich jetzt auch nicht.
- Was bedeutet Ws_WID bzw. Ser_SID?
Die Server usw. haben alle eine eigene Nummer die sich aus der Kundennummer und dem Datum usw. zusammenstellt. Deswegen Ws_WID usw.
- Das reduntante Abbilden von Foreign-Keys (Dunden_ID) halte ich auch für ungeschickt. Constraints mit eingeschaltetem CASADE DELETE sollten auch ohne dieser Maßnahme in der Lage sein, alle Daten zu löschen, die beispielsweise dem zu löschenden Kunden zugeordnet sind.
Ok, kannte ich ehrlich gesagt bis vor kurzem selber noch nicht. also das mit CASADE DELETE. Kannte nur Not Null und UNIQUE usw.
- Die Namensgebung halte ich z.T. auch mißlungen. imho wäre es besser die Foreign-Key-Spalten gelcih wie die zugehörige Primary-Keyspalte zu benennen. Nach dem Motto "Einmal Kund_ID, dann immer Kund_ID".
Hm dachte es wäre so übersichtlicher. Aber ok.
Vielen Dank!
Gruß Christoph
--
Ich bin ein spezialisz!
(Zitat von VENGA JO)
sh:) fo:) rl:° br:& ie:| mo:) va:) fl:) ss:| ls:< js:|
Die Erklärung zum Selfcode findest du hier: http://emmanuel.dammerer.at/selfcode.html
Einen Decoder für den Selfcode findest du hier: http://peter.in-berlin.de/projekte/selfcode
Ich bin ein spezialisz!
(Zitat von VENGA JO)
sh:) fo:) rl:° br:& ie:| mo:) va:) fl:) ss:| ls:< js:|
Die Erklärung zum Selfcode findest du hier: http://emmanuel.dammerer.at/selfcode.html
Einen Decoder für den Selfcode findest du hier: http://peter.in-berlin.de/projekte/selfcode