Mailinglisten-Archive |
andreas amalesh kempf wrote: > Hmmm, ich kenne postgres nicht besonders, aber IMO erfordert > postgres eine sonderbehandlung bei BLOB's, richtig? Alle Datenbanken erfordern eine Sonderbehandlung bei BLOBs. Das liegt daran, daß es schlicht nicht effizient ist, einen Result Set mit n Elementen mit darin enthaltenen BLOBs zu saugen, wenn das n gross ist und die BLOBs ebenfalls gross sind. Außerdem ist SQL eine ASCII-Abfragesprache und Binärmüll läßt sich da nur eingeschränkt bequem in die Query einbetten. Die meisten Datenbanken liefern bei BLOB-Ergebnissen nur BLOB-Handles im Result Set und erlauben dann, einzelne BLOBs separat über das Handle zu fetchen. Insbesondere hat man dann die Möglichkeit, innerhalb es BLOBs zu positionieren oder nur Teile des BLOBs zu fetchen, was bei einem potentiell 4 GB großen Monster u.U. auch angebracht ist. MySQL liefert BLOBs inline, hat dann aber nachher bei großen BLOBs probleme, sich auf der Verbindung nicht an den dicken Klötzen zu verschlucken (Buffer-Size und dergleichen). MySQL ist für Webanwendungen vor allen deswegen nett, weil es so schöne low-cost connects hat, sodaß man auch mit CGI PHP noch was wird. Außerdem ist es sehr viel schneller als richtige Datenbanken, weil es keine Transaktionen kann. Mit MySQL stirbt man, sobald man eine Anwendung mit mehreren Multi-Table Updates hat oder sobald man eine Anwendung hat, die nicht mehr read-mostly-Natur hat. Hier ist es unbedingt angezeigt, schon in der Analyse- oder Designphase eine richtige Datenbank ins Auge zu fassen. Ich habe da mal einen längeren Artikel auf der englischen Liste zu diesem Thema geschrieben: http://db.geocrawler.com/archives/3/1/1999/5/0/1796865/ http://db.geocrawler.com/archives/3/1/1999/5/0/1806809/ Kristian -- Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00 Using PHP3? See our web development library at http://phplib.shonline.de/ (GPL)
php::bar PHP Wiki - Listenarchive