Also,
eine gescheite Datenbankdokumentation sorgt dafür, dass die Daten fürs Re-Engineering gar nicht in der Datenbank abgespeichert werden müssen. Dafür reicht i.d.R. bereits der Einsatz von Microdoof Visio oder eines entsprechenden Derivats.
Zur Transaktionskontrolle: Da sollte euer Entwickler wissen, dass das ar...-langsam wird. Deswegen wurden ja die atomic operations bei myISAM eingeführt. Um Probleme bei Data Transactions zu umgehen, stellt mySQL bei myISAM bereits LOCK TABLE zur Verfügung. Ausserdem lässt sich die Transaktionskontrolle "simulieren", indem man temporäre Tabellen erzeugt.
Zudem gesteht sich selbst mySQL AB ein, dass die Transaktionskontrolle noch nicht ausgereift ist und dies auch nie werden wird. Ich zitiere die mySQL-Dokumentation, Kapitel "Transactions and atomical operations":
| Zitat: |
Even a transactional system can lose data if the server goes down. The difference between different systems lies in just how small the time-lap is where they could lose data. No system is 100% secure, only ``secure enough.'' Even Oracle, reputed to be the safest of transactional database systems, is reported to sometimes lose data in such situations. To be safe with MySQL Server, whether using transactional tables or not, you only need to have backups and have the binary logging turned on. With this you can recover from any situation that you could with any other transactional database system. It is always good to have backups, independent of which database system you use.
|
Zum Thema "Geschwindigkeit" aus dem selben Kapitel:
| Zitat: |
However, even if you are new to the atomic operations paradigm, or more familiar with transactions, do consider the speed benefit that non-transactional tables can offer on the order of three to five times the speed of the fastest and most optimally tuned transactional tables.
|
Zu den Risiken von Transaktionen lässt sich die Doku ebenfalls aus (nämlich das ungewollte Rollback):
| Zitat: |
| ``Atomic,'' in the sense that we mean it, is nothing magical. It only means that you can be sure that while each specific update is running, no other user can interfere with it, and there will never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there will not be any dirty reads. |
Man verzeihe mir meine radikale Sicht der Dinge, aber Transaktionskontrolle wird nur von Leuten benötigt, die schon vorher wissen, dass Sie selbst oder Ihr Programm Fehler macht.
Warum konvertiert ihr die Daten von einem Datenbanksystem in ein anderes? Wenn Ihr auf einem System eine Datenerfassung und Aufbereitung und auf dem anderen System (2 getrennte Server) eine Datenauswertung fahrt (man merke an: Iterative Datenauswertung benötigt bei mySQL erheblich länger als Datenaufbereitung, wenn damit interne Statements gemeint sind. Grund: Die Auswertung unterstützt sämtliche Tabellenverknüpfungen, die Aufbereitung hingegen nicht!) dann benutzt doch einfach eine One-Way-Replikation. Wenn Ihr hingegen auf einem System eine Datenerfassung und auf dem anderen eine Datenaufbereitung macht, dann macht einfach einen Dump über die Servergrenze hinweg.
Fernab dessen ist mySQL mit Beowolf clusterbar. mobile.de zum Beispiel bereibt einen sehr großen mySQL-Cluster.
Nächste Frage: Warum setzt ihr auf EMS? Wer weiß denn schon, wie lange es die Firma noch gibt? Wenn man schon die Vorteile eines freien Datenbanksystems nutzt, warum sollte man diesen Vorteil durch kommerzielle Module kaputt machen? (Sag selbst ich, der sein Geld mit kommerziellen mySQL-Tools verdient *g*)
Solltet ihr die Foreign-Keys innerhalb eurer Programmlogik benötigen, weil euer Programmierer nicht richtig mit JOINs umgehen kann: mySQL wird in absehbarer Zeit auch für myISAM Foreign Keys anbieten.
| Zitat: |
| For other table types, MySQL Server currently only parses the FOREIGN KEY syntax in CREATE TABLE commands, but does not use/store this info. In the near future this implementation will be extended so that the information is stored in the table specification file and may be retrieved by mysqldump and ODBC. At a later stage, foreign key constraints will be implemented for MyISAM tables as well. |
Die Dokumentation nennt beim Einsatz von Foreign Keys eine ganze Reihe von Nachteilen:
| Zitat: |
Mistakes, which are easy to make in designing key relationships, can cause severe problems--for example, circular rules, or the wrong combination of cascading deletes.
Additional checking on the database level affects performance, for this reason some major commercial applications have coded this logic on the application level.
It is not uncommon for a DBA to make such a complex topology of relationships that it becomes very difficult, and in some cases impossible, to back up or restore individual tables.
|
Um noch einige Nachteile von InnoDB hinterherzuwerfen:
www.mysql.com/docume...#InnoDB_restrictions
Und um die allererste Frage zu beantworten, ob InnoDB in der freien Version eine Beschränkung hat:
| Zitat: |
The default database page size in InnoDB is 16 KB. By recompiling the code one can set it from 8 KB to 64 KB. The maximun row length is slightly less than half of a database page in versions <= 3.23.40 of InnoDB. Starting from source release 3.23.41 BLOB and TEXT columns are allowed to be < 4 GB, the total row length must also be < 4 GB. InnoDB does not store fields whose size is <= 128 bytes on separate pages. After InnoDB has modified the row by storing long fields on separate pages, the remaining length of the row must be less than half a database page. The maximun key length is 7000 bytes.
On some operating systems datafiles must be < 2 GB. The combined size of log files must be < 4 GB.
The maximum tablespace size is 4 billion database pages. This is also the maximum size for a table. The minimum tablespace size is 10 MB. |
Viele Grüße,
Matthias
P.S.: Ich hab kein Problem damit, wenn man mir widerspricht und lasse mich gerne eines besseren belehren
