Zum Inhalt springen

Diskussion:Datenbanksystem

Seiteninhalte werden in anderen Sprachen nicht unterstützt.
aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 29. Dezember 2005 um 11:02 Uhr durch Frank Roeing (Diskussion | Beiträge). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Hoch offene Fragen:

  • Datenbankformate: Welcher Standard setzt sich durch? D.h. in welchem Format lassen sich Daten austauschen?

Basisformat CSV? XML? ganz sicher xml, ggf später auch andere sgml anwendungen. --HJG 23:04, 27. Mär 2005 (CEST)

  • Wie kann man Tabellen ineinander überführen? (Wie ist diese Frage zu verstehen?)

objektrelationales mapping xml nach tabelle und zurück, tabelle in tabelle vielleicht per view?

  • Wie kann man HTML Tabellen in dBase-, Excel- oder Access-Tabellen überführen?

die frage hat hier nichts verloren.

Antwort: Die meisten DBMS haben Import-Funktionen mit denen man Tabellen verschiedener Formate in eine Datenbank importieren kann. Dort kann man sie dann zusammenführen und ggfs. wieder exportieren

HTML-Tabellen: Ein möglicher work around ist, dass die HTML-Tabelle zunächst mit MS Word geöffent und in ein normales Word-Dokument umgewandelt wird. Dort wiederum kann die Tabelle in Text umgewandelt werden (z.B. Tab-Delimited) und dieser Text wiederum wird im ASCII-Format gespeichert. Die Ascii-Datei läßt sich wiederum von DBase, Excel und Access importieren. - Da allerdings HTML ein einfach zu parsendes ASCII-Format hat, kann ohne weiteres ein Konverter geschreiben werden, der gleich eine importierbare Datei erzeugt, sofern nicht sofort das Zielformat anprogrammiert wird. (Na, ob das Kochrezept in die Wikipedia passt?) -- Karlscharbert 02:52, 2. Dez 2003 (CET)

Antwort: Ein Datenmodell ist ein Entwurf, der das "Wie" der Speicherung der Daten verdeutlichen soll. Beim Design einer Datenbank muß darauf geachtet werde, daß keine Daten in verschiedenen Tabellen erscheinen. In jedem Feld sollte nur eine Information über ein bestimmtes Objekt stehen (z.B. Vor- und Nachname einer Person in zwei Feldern und nicht in nur einem). Auch müssen Primärschlüssel und Inizes festgelegt werden usw. usf.

--> man lese die normalformen, außerdem gibt es verschiedene paradigmen für den datenbankentwurf, der tabellenorientierte ist nur eine mögliche, nämlich relationale variante. man kann daten auch objektorientiert modellieren, andere verfahren gibt es,sind aber nicht so bedeutsam --HJG 23:04, 27. Mär 2005 (CEST)

  • Der Begriff "Relation" ist m.E. nicht korrekt verwendet, aber vielleicht hat der Autor hier andere Literatur verwendet als ich es gelernt habe, daher stelle ich das erst Mal zur Diskussion. Eine Relation ist in der Mathematik "eine Teilmenge des kartesischen Produkts von Mengen" und bezeichnet nicht die Beziehungen(!) zwischen den Tabellen, sondern die Tabellen selbst. Diese enthalten nämlich nichts anderes als das kartesische Produkt der Wertebereiche ihrer Spalten. Möglicherweise hat sich hier ein "falscher Freund" eingeschlichen: Im Englischen sind die Beziehungen zwischen den Tabellen nämlich die "table relations"... Unter Relationale_Datenbank steht die mit meinem Wissenstand übereinstimmende Definition --Xorph 11:41, 18. Mär 2004 (CET)
    • Nachdem kein Einspruch erfolgt ist, ändere ich das jetzt --Xorph 11:19, 25. Mär 2004 (CET)
      • dieser fehler ist in IT-kreisen weit verbreitet. das könnte man noch dazusagen. -- ∂ 05:29, 10. Okt 2004 (CEST)

zwischen den tabellen git beziehungen mit bestimmten kardinalitäten. der relationsbegriff beschreibt nicht die verhältnisse zwischen tabellen. --HJG 23:04, 27. Mär 2005 (CEST)

  • Der Begriff "Kunde" ist in Bibliothekskreisen mehr als umstritten. Um das Beispiel realistischer zu machen, schlage ich vor, "Kunde" durch den üblichen Begriff "Benutzer" oder "Nutzer" zu ersetzen. Ich plädiere für letzteres. CH, 11.06.2004, 11:43 CET
    • Im Beispiel ist der (Be)Nutzer der Datenbank aber der "Ausleiher". Das wäre noch verwirrender. Softeis 18:06, 15. Sep 2004 (CEST)

im softwaretechnischen umfeld, sprich da, wo die systeme entworfen werden, verwendet man "Akteur" für alle personen und/oder maschinen welche aktionen an dem zu beschreibenden system auslösen oder ausgaben des systems wahrnehmen können. konsistenter weise sollte man den begriff des akteurs auch hier verwenden. klassisch wäre user / nutzer / benutzer aber auch üblich. die modernisierung auf akteur ist aber überfällig und ich würde die sehr begrüßen --HJG 23:04, 27. Mär 2005 (CEST)

  • Was genau ist ein Sekundärschlüssel, wo sind Unterschiede zum Primärschlüssel? --Tina
    • Mit Hilfe des Primärschlüssels selektiere ich in einer relationen Datenbank einen Datensatz eindeutig und (weil dem Primärschlüssel ein Index zugrunde liegt) auch schnell. Wenn in einer Kundentabelle beispielsweise jeder Kunde eine eindeutige "Kunden-ID" besitzt, dann wäre diese Kunden-ID der ideale Primärschlüssel zur eindeutigen Kennzeichnung eines jeden Datensatzes. Wenn ich den Datensatz später ändern oder löschen möchte, dann brauche ich bei den jeweiligen "update"- oder "delete"-Anweisungen nur anzugeben, welche "Kunden-ID" von der Änderung betroffen werden soll (also nicht noch zusätzliche Einschränkungen wie "Vorname", "Nachname", etc.). Der Primärschlüssel ist also in diesem Sinne das wichtigste und erstrangig verwendete Selektionskriterium, um Daten in einer Tabelle zu selektieren (primär: erstrangig, am wichtigsten, in erster Linie, hauptsächlich, vordergründig). Eine Datenbanktabelle kann jedoch neben dem Primärschlüssel noch weitere Indizies besitzen. Wenn es bei einer Kundentabelle beispielsweise oft vorkommt, daß Kunden innerhalb eines bestimmten Postleitzahlbereichs selektiert bzw. sortiert werden müssen, dann könnte es sich lohnen, die Spalte "Postleitzahl" auch mit einem Index zu versehen, damit die Selektion oder Sortierung der Kunden nach Postleitzahlen schnell vonstatten geht. Da die Tabelle mit der "Kunden-ID" aber bereits einen Primärschlüssel hat (es kann nur jeweils einen Primärschlüssel pro Tabelle geben), würde es sich bei dem Index auf der Spalte "Postleitzahl" um einen Sekundärschlüssel, also zusätzlichen (sekundär: nachgeordneten, zweitrangigen) Schlüssel handeln. --Remi 00:01, 12. Okt 2004 (CEST)

sollte das nicht vielleicht eher in die wikibooks rein? für ein lexikon geht diese (ganz gute) erklärung ein wenig sehr ins detail finde ich. --HJG 23:04, 27. Mär 2005 (CEST)

Normalformen

Der Abschnitt mit den Normalformen ist zwar korrekt geschrieben, aber wer keine Kenntnis über Datenbanken besitzt wird mit der Erklärung nichts anfangen können. Wäre mal eine Überarbeitung Wert. -- Herr Schroeder 14:57, 8. Dez 2004 (CET)

Nicht nur das, der Abschnitt gehört hier gar nicht hin, sondern eher zu den relationalen Datenbanken.

Es gibt auch noch den Artikel Normalisierung (Datenbank) -- also was jetzt?! -- Nol Aders 18. Mai 2005

Habe den Vorschlag aufgegriffen und die Normalformen entfernt, aber unter Siehe auch hingewiesen. --UlrichJ 12:36, 31. Mai 2005 (CEST)

Produkte

Hallo Datenbänker,

ich finde die Datenbankprodukte ziemlich unübersichtlich. Ausserdem gibt es eine eigene Kategorie:Datenbankmanagementsystem dafür. Wir sollten also diese alberne Liste, die eh keiner Liste löschen.

-- Sparti 18:31, 15. Feb 2005 (CET)

s. anregung wikibooks

Habe obige Anregungen aufgegriffen und "Verschiedene Datenbankverwaltungssysteme" gelöscht, nachdem ich alle Systeme, die (noch) nicht in der Kategorie Datenbankmanagementsysteme auftauchen, hier gerettet habe:

--UlrichJ 14:09, 31. Mai 2005 (CEST)

Pars pro toto

Ich finde den Artikel insgesamt recht gelungen, ABER er macht einen Fehler, der häufig gemacht wird.

Wenn gesagt wird ... 

      "Eine Datenbank ist die elektronische Form eines Karteikastens."

bzw. 

      "Das grundlegende Element einer Datenbank ist der Datensatz (er entspricht einer Karteikarte).
       Aus einer gewissen Anzahl von Datensätzen wird eine Tabelle oder Liste gebildet."

... dann wird hier nicht Datenbank im allgemeinen beschrieben, sondern eine bestimmte Datenbankart, nämlich relationale Datenbanken! Natürlich basieren andere Datenbankarten NICHT auf dem Konzept der Tabelle oder der Liste. Auch ob das grundlegende Element einer Datenbank IMMER ein "Datensatz" ist, darf wohl bezweifelt werden. Gegen das Bild des Karteikastens würden sich wohl ebenfalls alle Datenbankarten jenseits des relationalen Modells wehren.

Kann diese Sätze bitte mal jemand ändern, der es schafft, die Balance zwischen Allgemeinheit der Definition und klarer Verständlichkeit zu bewahren?

Danke schön, ps (20.4.05)

Hallo Danke für den Hinweis, ich schliesse mich der Kritik an. Übringens, wenn Dir so ein Fehler auftritt ist es am einfachsten, Ihn einfach zu korrigieren :-)

Auf der Informatik Seite habe ich bereits eine andere Defintion der Datenbank verwendet, vielleicht ist die ja brauchbarer?

Ich werde mich die Tage mal dem Artikel annehmen.

-- Sparti 09:29, 20. Apr 2005 (CEST)

Ahoi, ich finde den Vergleich für die Allgemeinheit brauchbar, also "gut genug", und würde ihn daher stehen lassen.

Fragment 10:46, 6. Aug 2005 (CEST)

Hmmm, natürlich hat eine Erklärung durch Vergleich mit einem allgemein bekannten Sachverhalt (oder Ding) den Charme, an das BILDhafte denken der Leute zu appellieren und damit eine potentiell höhere Leserschaft zu erreichen, aber mir fehlt dabei der Abstraktionsgrad, den eine gute Erklärung eines Konzeptes (wie z. B. des zur strukturierten Datenspeicherung) aufweisen sollte -- gerade in einem Lexikon. Mein Vorschlag wäre (jetzt mal so aus dem Bauch heraus): 

      "Eine Datenbank ist eine Möglichkeit, gleichartige Informationen, die sogenannten Datensätze, 
      strukturiert abzuspeichern und durch Suchanfragen gezielt wiederzufinden."

--Dumbledork 16:55, 4. Okt 2005 (CEST)

ORDBMS

Ich weiß das folgende nicht genau genug, deswegen möge freundlicherweise jemand mit Ahnung die Änderung durchführen: Da Oracle, ein sehr großer Hersteller von RDBMS, mit der Version 8 seiner Software ein objektrelationales Modell implementiert hat, sind objektrelationale Datenbanken inzwischen auch sehr verbreitet.

Fragment 10:47, 6. Aug 2005 (CEST)

XML?

Sollen wir nicht noch einen kurzen Absatz über XML ("semistrukturierte Datenmodelle", "selbstbeschreibende Datensätze" o.dgl.) reinpappen?

Fragment 10:49, 6. Aug 2005 (CEST)

Es gibt bereits einen Artikel XML-Datenbank, hat es etwas damit zu tun? -- sparti 21:26, 6. Aug 2005 (CEST)
Ungefähr, ja ... der Trick ist, dass DBMS die Daten stark vorstrukturieren, während XML das Datenformat abstrakt beschreibt, und danach die Daten angibt. Es eignet sich also für Daten, deren Struktur Änderungen unterliegt. Mache ich auch morgen, ich kuck vorher nochmal ins Buch. Ahoi, Fragment 01:29, 7. Aug 2005 (CEST)

Laufendes Beispiel?

Ahoi, ich schon wieder, für den ganzen Datenbankkram sollte man vernünftigerweise ein für allemal ein einziges Beispiel haben, klassisch die Bibliothek oder auch klassisch Kunde, Auftrag, Lieferant. Sonst denkt sich jeder immer wieder eigene Beispiele aus. Fragment 14:01, 6. Aug 2005 (CEST)

Das waere sehr schoen. Leider gibts bereits eine Menge Artikel mit verschiedenen, sehr gut ausgearbeiteten Beispielen, das zu aendern heisst sehr viel Arbeit. -- sparti 21:28, 6. Aug 2005 (CEST)
Umpf, Arbeit? So'ne Sklavenarbeit kann ich nur gut im Team. Bin raus, Ahoi, Fragment 01:37, 7. Aug 2005 (CEST)

"Siehe auch" - XBase

Ahoi, ich hatte gerade eine kleinere Diskussion mit Benutzer:DutiesAtHand bzgl. seines XBase-Links, den ich reverted (und dies begründet) habe. In der Produkte-Diskussion oben gab es so ein Thema ja schon mal.

Der Link ist inzwischen wieder drin.

Meine Meinung: Einzelne DBMS haben in der "Siehe auch" Liste nix verloren. Die sollten nach DBMS oder in den leidigen Artikel Datenbank (Liste). Grund: Sonst kommt jeder daher und stellt sein Steckenpferd-DBMS in den Siehe-Auch-Abschnitt.

Die Artikel, die ich alternativ vorgeschlagen hatte, sind bis dato unverändert.

Seine/Ihre Meinung steht in meiner Diskussionsseite. Ich stimme insoweit zu, dass aus dem Siehe-Auch-Abschnitt das eine oder andere mal rausfliegen könnte. Ich stimme auch zu, dass die Klasse der dBase-Datenbanksysteme eine Erwähnung wert sind - nämlich im Fließtext, unter Geschichte.

Rausfliegen können m.E.:

Ich fürchte, nun auch

  • Xbase - Sammelung spezifischer DBMS der dBase-Klasse

Grüße, Fragment 18:33, 23. Aug 2005 (CEST)

Eine CSV Datei ist meines Erachtens auch eine Art Datenbank und wird für strukturierte Datenspeicherung aus genau dem Grund eingesetzt. Würde hier also (an passender Stelle) durchaus Sinn machen.
MVCC gehört zu relationalen Datenbanken und kann hier angeschnitten und verlinkt werden.
Der Rest gehört hier nicht hin, stimmt.
Ads 23:16, 23. Aug 2005 (CEST)


Ich stimme Fragment vollkommen zu, insbesondere und ausdruecklich auch seiner Meinung zum Xbase Link. Es gibt einfach zu viele Formate/Produkte dieser Art und die gehoeren hier nicht hin und uebrigens auch in DBMS. Meinetwegen koennen wir eine Liste fuehren.
Auch kann ich nicht erkennen, warum MVCC eine Sonderrolle einnehmen sollte.
Lediglich ein Hinweis auf eine CSV Datei sollte vielleicht da sein. Aber nicht unter siehe auch, sondern besser als Beispiel fuer eine einfache Datenbank.
Gruss sparti 00:16, 24. Aug 2005 (CEST)
Ich sagte ja für CSV "an geeigneter Stelle", aber schliesslich erklären wir hier Datenbanken und dazu gehört das nun mal auch. Datenbanken bestehen nicht nur aus Software, die man per SQL anspricht (obwohl es selbst dafür mittlerweile Layer gibt ...)
Zu MVCC: wenn wir schon Features von relationalen Datenbanken in einem Absatz aufzählen und erklären, gehört das definitiv mit dazu. Da es eine eigene Seite dafür gibt, reicht eine kurze Erläuterung und der Verweis auf die Seite.
Ads 19:17, 24. Aug 2005 (CEST)
Ich halte den MVCC zu weitgehend. Wenn wir damit naemlich anfagenen, dann muessen wir auch ACID erlaeutern und eigentlich auch, wie ein Optimierer und die Cacheverwaltung funktioniert etc. Damit machen wir ein Fass ohne Boden auf. Das gehoert wenn ueberhaupt in RDBMS.
Im Artikel werden bisher nur Konzepte, keine technischen Details erlaeutert. Selbst das finde ich geht oftmals schon zuweit und gehoert woanders hin. Naja, aber wenn Du auf den Link bestehst koennte ich damit leben. Mit XDbase koennte ich allerdings nicht leben :-) -- Gruss sparti 23:59, 24. Aug 2005 (CEST)
Meiner Meinung nach hat CSV mit Datenbanken genauso wenig zu tun wie etwa Excel. Eine CSV-Datei bietet nämlich keine Möglichkeit zur gezielten Abfrage von Daten, sondern speichert spärlich besetzte Felder (sparse arrays) in einem Freiformat.
Nur weil man die Daten einer Relation(!) nach CSV exportieren kann, um sie dann in eine andere Relation mit den gleichen Attributen zu importieren, ist eine CSV-Datei noch keine Datenbank. Dann nehmt lieber die XML-Dateien auf, die kann man nämlich auch mit XPath/XQuery durchsuchen, und nicht nur mit Volltextsuche/regulären Ausdrücken. Einen Link für CSV-Dateien unter siehe auch würde ich aber schon sinnvoll finden.
Nur so meine 2 Euro-Cent, --Dumbledork 17:19, 4. Okt 2005 (CEST)
Nun Du kannst eine XML Datei ebensowenig abfragen, wie eine CSV Datei oder ein Raw Device, die eine Datenbank enthalten. Aber ein Datenbankmangementssystem kann das durchaus. Und genau das macht den Unterschied aus. -- Gruss sparti 20:04, 4. Okt 2005 (CEST)

Hallo,
irgendwie prallen hier wohl doch verschiedene Wikipedia-Verständnisse zusammen. Wikipedia soll doch Informationen vernetzen! Das passiert doch vornehmlich durch Links. Das Xbase als Generalisierung von dBase dann in diesen Artikel reingehört, scheint ja s.o. geteilt zu werden. Solange es nicht im Fließtext vorkommt, finde ich Siehe auch sehr passend. Link behalten --DutiesAtHand 08:13, 24. Aug 2005 (CEST)

Nein, wir haben die selbe Vorstellung von Wikipedia, aber eine unterschiedliche Vorstellung von der Bedeutung XBase. Es gibt heute eine 4.874 Billarden Datenbanken, davon sind vielleicht Oracle, MSSQL, DBase und MySQL aus verschiedenen Gruenden besonders erwaehnenswert. Das gehoert dann aber in DBMS, wie Fragment schon sagte. Alles andere gehoert in Datenbank (Liste) oder haelst Du diese Liste fuer so interessant, dass man sie unbedingt vernetzen muss? -- Gruss sparti 10:27, 24. Aug 2005 (CEST)
Ahoi, bitte nicht absichtlich missverstehen! PC-"DBMS" sollten hier erwähnt werden und dBase als wichtiger Vertreter aus der mittleren Steinzeit. Ich habe nicht von dem XBase-Artikel gesprochen - ich habe den Link nicht umsonst zunächst reverted und diese Diskussion hier angefangen! Ich bin klar contra einzelne DBMS im Siehe-Auch-Abschnitt! Fragment 22:36, 24. Aug 2005 (CEST)

Ja, warum nicht mal mit der Axt ...

Uuufff, also, die Änderungen heute waren GUT :-) ... ABER ... jetzt müssen wir alle ganz viel arbeiten ...

  1. Ein allg. Beispiel für das ganze DB-Thema könnte evtl. in einen eigenen Artikel Laufendes Beispiel (Datenbank), und ruhig komplexer, und für die anderen Artikel auch verwendet werden ... oh oh ...
  2. Primärattribute werden normal unterstrichen
  3. Geschichte erweitern, Magnetbänder, SQL und SQL-Standards erwähnen
  4. Modelle: "Sonderfälle" sind spezialisierte DBen, alte DBen, verteilte DBen, modernes Zeugs, ISAM ist KEINE Datenbank, sondern ein Format, um DB-Inhalte auf der internen Ebene zu speichern (MySQL benutzt IMO ISAM)
  5. Verwendung: Erstes Codd'sches Prinzip war: Integration aller Datenbestände, moderne Filesysteme gehen in diese Richtung. Evtl. Codd'sche Prinzipien erwähnen und erläutern.
  6. Modelle: Objektrelationale DB fehlen und sind wichtig: Orakel geht in diese Richtung
  7. 3-Ebenen-Modell fehlt, insbesondere in Abgrenzung zu hierarchisch/Netzwerk

Grüße, Fragment 02:21, 26. Aug 2005 (CEST)

Gute Punkte. Ich halte aber Objektrelationale Datenbanken in der Praxis fuer wenig relevant. Ich kenne niemanden der weiss wie man die Funktionalitaet in Oracle nutzt :-) Ich denke es reicht Objektorientierte Datenbank zu erlaeutern, die "Hybride" sind doch eher Workarounds. -- Gruss sparti 10:45, 26. Aug 2005 (CEST)

CSV

CSV wird im Artikel als kommaseparierte Datendatei (engl.: comma-separated value file oder kurz CSV file) beschrieben. Demgemäß heißt es auch, die Attribute würden durch Kommata getrennt. Dies erscheint mir unvollständig. Meiner Ansicht nach sollte man von charakter-(oder zeichen-)separierten Werten sprechen (character-separated values), da als Trennzeichen häufig auch andere Zeichen als das Komma, beispielsweise das Tabulatorzeichen verwendet werden. (Michael Stehmann)

Die Bedeutung von CSV hat sich über die Zeit ein wenig geändert und ist leider nicht ganz präzise. Die Bedeutung selbständig umzuändern halte ich aber für bedenklich. Außerdem wird im Artikel CSV die Möglichkeit anderer Trennzeichen erklärt. Ich plädiere deswegen dafür, den momentanen Text beizubehalten.--Harmonica 06:01, 9. Okt 2005 (CEST)
zitat von csv-datei: "Das Kürzel CSV steht dabei für Character Separated Values oder Comma Separated Values". in der englischen wikipedia steht nur comma-sv.
afaik bedeutete csv anfangs tatsaechlich nur comma-sv, aber mittlerweile wird auch immer haeufiger mal - und nicht nur in der wikipedia - von character-sv gesprochen und geschrieben. man kann es also evtl. als backronym ansehen, wobei ich dafuer keine quellen angeben kann. imho darf man ruhig von character-sv reden und schreiben.--seth 23:03, 17. Okt 2005 (CEST)
Ich habe den Begriff Character Separated auch noch nicht gehoert. Auch wenn er sinngemaess richtiger waere, ergibt eine Google Suche, ein recht klares Bild fuer den Begriff Comma Separatated. Und so sollten wir es dann auch verwenden. -- Gruss sparti 08:22, 20. Okt 2005 (CEST)

Ich würde den Abschnitt über CSV komplett entfernen, da es sich dabei um kein Datenbankmodel handelt, sondern eher um ein Dateiformat. Daten(bank)model: System von Konzepten zur Strukturierung und Modellierung von Datenbeständen. --84.131.28.130 17:14, 27. Nov 2005 (CET)


Das Lemma heisst ja auch Datenbank und nicht Datenbankmodell ! -- Gruss sparti 04:34, 28. Nov 2005 (CET)
Aber der Abschnitt CSV steht unter Datenbankmodelle oder nicht? -- Gruß --Lex912 17:21, 28. Nov 2005 (CET)
Ja, Du hast recht, die Ueberschrift ist nicht passend. -- sparti 19:32, 28. Nov 2005 (CET)
PS.: Das war nur ein Scherz. Die Ueberschrift ist gut und der Absatz beschreibt den Inhalt sehr gut. Dort wird nirgendwo behauptet, dass eine CSV Datei ein Datenbankmodell ist, sondern nur dass es Teil davon sein kann. Und das ist eben wichtig zu verstehen. -- sparti 19:43, 28. Nov 2005 (CET)

Noch einmal von vorn?

Meiner Meinung nach sollte das Pferd noch einmal neu aufgezäumt werden, natürlich ohne die Verbesserungen der letzten Monate, insbesondere des Zeitraums 8/9 2005 zu vergessen.

Was mich an dem Artikel stört, ist die mangelnde Abgrenzung gegenüber der herkömmlichen Dateiverarbeitung. Man schlage mal bitte einer Firma oder einem Institut vor, Datenbanken auf CSV-Basis zu betreiben, das kann nun wirklich hier nicht ernsthaft stehen bleiben. Aber ich will ja auch erstmal diskutieren, und das mit dem folgenden Vorschlag:

  • Dieser Artikel wird eingekürzt und auf den Begriff Datenbank im Sinne des eigentlichen Speichers in DB-Systemen gebracht. Darin steht dann wohl eher der Begriff ISAM-Zugriff im Vordergrund, denn CSV. ISAM ist Datenbank-Format in SQL Server, ORacle, DB2/UDB, ...
  • Der Artikel "Datenbank-System" wird stark ausgebaut.

Werde mich in gerne in den nächsten Tagen dem letzteren Artikel widmen, um weiteren Diskussionsstoff zu liefern. Hier in diesem Artikel warte ich erst einmal auf Meinungen. Glück Auf, --EFR 10:02, 29. Dez 2005 (CET)

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:Datenbanksystem&oldid=12070471“