nicht angemeldet
yo,
ich denke mal, wir sollten eins klären, da du es aus irgend einem grund immer wieder mit anführst. ich schreibe niemanden vor, was er tun sollte. jemand hat gefragt, ich habe meine meinung zum besten gegeben. nicht ich habe die meinung eines anderen angezweifelt, sondern umgekehrt, hat christian die diskussion ins rollen gebracht, worüber ich auch in keinster weise böse bin. nur eben meine meinung und standpunkte würde ich gerne vertreten können. insofern macht es wenig sinn, das als argumentationsmittel immer wieder aufzuführen, ich schreibe angeblich anderen etwas vor.
Stimmt, du schreibst nicht vor, du sagst nur, sie wären in jedem Fall suboptimal.
- in vielen fällen einfacher umzusetzen ist, als die programmierung selbst vornehmen zu müssen.
Ja, in vielen, aber nicht in allen, inklusive in dem Fall nicht (solange er nicht eine spezielle Nutzung der Daten angibt).
- ich datenunabhängikeit erhalte, was für mich mittelbar oder in der zukunft wichtig ist. und wie der name zukunft schon sagt, man kennt sie nicht. so kann ich auch sicherstellen, dass unterschiedliche pogramme diese daten nutzen können.
Falls das abzusehen ist, stimme ich dir bedingt zu. Falls alle Programme die in der selben Art benötigen und diese Zugriffsart einfach ist, würde ich das über eine Bibliothek lösen. Damit habe ich die selben Vorteile ohne den Overhead zu haben.
- ein dbms bei nicht statischen daten schneller ist.
Das ist schlicht und einfach falsch. Es kann schneller sein, ist es manchmal auch, aber genauso oft ist es langsamer. Es wird in jedem Fall langsamer sein als eine perfekt auf die Anwendungen und Daten zugeschnittene Lösung. Die Frage ist nur, ob sich der Aufwand dafür lohnt oder nicht. Meistens tut er es nicht-
- es eine sehr einfache benutzerverwaltung der daten gibt, so dass nicht jeder alle daten sehen/ändern kann, sondern nur die gewünschten
Ja, ist nur nicht immer gewünscht.
die diskussion über den sinn von datenbanken gab es meiner meinung schon vor jahren, wo man die notwendigkeit erkannt hat und schließlich angefangen hat, dbms zu entwickeln. nartürlich sei jedem eine andere ansicht darüber gegönnt. besonders cräcks, die alles viel besser können, für die es quasi nur ein schnippsen mit den finger bedeutet, das alles umzusetzen, die der meinung sind, die kochen ja alle eh nur mit wasser, bitte sehr. ich für meinen teil würde ein dbms benutzen, solange es sich nicht um private daten handelt.
Datenbanken sind sinnvoll, das bestreitet niemand, nur nicht für jede Anwendung und alle Anforderungen. Du würdest also auch sämtliche Konfigurationsdaten deiner Applikation in Datenbanken ablegen? Manche Daten gehören in Datenbanken, andere nicht, aber nur das eine oder andere einzusetzen, halte ich für viel zu stark vereinfacht.
lass mal die natur aus dem spiel, die ist nämlich auch wie die daten unabhängig. das problem der datei verwaltung der daten ist, dass man anfangs mit den gleichen ansätzen rangegangen ist, wie du nun auch argumentierst. man hatte feste strukturen und dachte, dass läßt sich doch wunderbar abbilden. das war aber sehr kurzsichtig, wie sich später herausgestellt hat. die unternehmen sind nämlich gewachsen oder haben sich verändert und somit haben sich auch die strukturen verändert. und genau das hat zu problemen geführt, dass sich ein unternehmen "der natur den daten" anpasen mussten. und daraus hat man gelernt, dass an eben nicht weiss, dass strukturen immer so bleiben, wie sie sind und genau aus diesem grund gibt es dbms.
Selbst mit Datenbanken hätte nicht einfach nur die Datenstruktur erweitert werden können. Ich habe sowohl mit solchen alten Ansätzen gearbeitet (von Files über hierarchische Datenbanken bis zu RDBMS und objektorientierten Ansätzen) und kann dazu nur eins sagen, egal welcher Ansatz, irgendwann kommt immer der Punkt wo du die Daten migrieren musst.
Oracle hat ein Haufen Begriffe, inklusive dem der Datenbank neu (falsch im Vergleich mit der Datenbanktheorie) definiert. Wenn du von der Oraclespezifischen Definition redest, musst du das sagen, ansonsten geh ich von der Definition aus, wie sie die Datenbanktheorie vorgibt.
ein checkpoint ist auch unter mssql kein abschluss einer transaktion. was du meinst ist ein commit befehl.
Nein, ein Commit-Befehl ist eine mögliche Implementierung eines Checkpoints. Ausserdem gibt es erheblich mehr Datenbanken als Oracle und MSSQL.
so weit ich es weiss arbeiten alle dbms so, dass sie erst die log-dateien schreiben und dann später die daten-dateien ändern. es wäre schwierig anders umzusetzen.
Gerade Oracle tut das nicht in jedem Fall. (Ja, ich habe genug Oracle Kurse gehabt). Die Logdateien werden aber auch auf HDs geschrieben, müssen sie ja auch zumindest ab dem Zeitpunkt, wo eine Transaktion abgeschlossen ist. Siehe dazu Definition einer Transaktion.
im falle eines fehlers muss ein logeintrag vorhanden sein, bevor daten-dateien geändert wurden. dies macht auch einen vorteil des dbms gegenüber dem datei-zugriff deutlich. bevor datenblöcke wieder auf die festplatte geschrieben werden, können mehrere tranasktionn auf die gleichen datensätze ausgeführt wprden sein und trotzdem schreibt er den entgültigen datensatz nur einmal auf die platte und nicht mehrmals.
Ich leugne nicht die Möglichkeiten eines DBMS, auch nicht das es eine gute und nützliche Erfindung ist. Es ist nur nicht immer die ideale Lösung.
Gruss Daniela