ein Grund, SQLite nicht zu nutzen

[frankx]

Ahoi,

»» »» »» Na wenn dann unserialize(file_get_contents("bla.blub")),
»» »»
»» »» Locking, anyone?
»»
»» Wenn nur einer schreibt und der Rest nur liest?

Ich wollt's nur mal erwähnt haben. SQLite macht das von alleine, und sobald es um größere Datenmengen geht, wird's ja beim Neuschreiben auch interessant, ob während des Schreibvorgangs Lesen auf halbfertige Daten möglich sind - und was das für Folgen hat.

Dann bleibt nur unserialize($row = $mysql->query("SELECT my_ser_data from single_table WHERE id = 1"))) oder in der Art (;-).

Die Spec lässt eindeutig zu viel Raum für Optionales:

• Die letzte Zeile kann CRLF am Ende haben, oder nicht.

Das lässt sich ja noch recht simpel workarrounden, aber eigentlich kein CRLF am Ende

• Die erste Zeile kann eine Header-Zeile sein, oder direkt Daten enthalten.

Das ist doch aber o.k., die Freiheit des Users/Programmierers.

• Felder können in Anführungszeichen stehen, müssen aber nicht.

Naja, eigentlich sollten sie nicht, es sei denn, es kommt Spalten oder Zeilentrenner drin vor.

Wenn du exakt EINE definierte Applikation hast, die dir dein persönliches CSV-Format auswirft, kannst du den Import auf diese Daten exakt abstimmen. Aber wehe, das Format ändert sich aus irgendeinem Grund...

Das ist ja immer klar. An die Definition muss man sich halten. Excel spuckt im Export-Modus Daten aus, die es im Import selbst nicht lesen kann. Zudem schaffst Du es nicht, beim exportieren die Delimiter festzulegen. Wenn Du aber VBAs asCSV-Funktion nutzt (oder wie die heißen mag), kommt wieder was anderes raus. Möglich, dass Excel das dann nicht lesen kann, und das andere schon. Excel immerhin verdirbt einem den Spaß daran, hätten die die streng gefasste Definition befolgt, hätte man diese ganze Diskussion vermutlich garnicht. (es gibt übrigens eigentlich drei ASCII-Zeichen, die als Trenner für sowas mal vorgesehen waren 29-31 oder so).

Dank und Gruß,

frankx