nicht angemeldet
Moin!
»» den gesamten Datenbestand im Speicher rumschleppst. Das kann sinnvoll sein,
Was wäre denn ein Paradebeispiel für Sinnvollsein in dem Zusammenhang?
Ich hab mal ein Skript geschrieben, das regelmäßig jede Minute einen Börsenkurs abgefragt hat. Weil der Kurs u.a. auf der Startseite eingebunden wurde, und auch per AJAX aktualisiert werden sollte, und weil es blöd war, für diese kleine Datenmenge irgendeinen anderen Speicher zu verwenden, hab' ich die Werte per Cronjob via PHP-CLI abgefragt und dann als include-Datei passenden PHP-Code auf Platte geschrieben.
Merkmale der Lösung: Winziges Problem, keinerlei Aussicht auf unendliche Ausdehnung, winzige Datenmenge, keine Möglichkeit, alternative Speicherlösungen zu nutzen.
3000+ Datensätze hätte ich damit nicht mehr verwalten wollen, die Aufgabe schreit eigentlich schon direkt nach einer Datenbank. Und insbesondere, wenn PHP mit SQLite schon eine integrierte Lösung mitbringt (sofern sie verfügbar ist), und man nicht noch separat eine z.B. MySQL-Datenbank beschaffen muss, wäre das definitiv meine Wahl.
Mit den entsprechenden DB-Abstraktions-Layern wie PDO ist auch der Zugriff verhältnismäßig standardisiert.
Eben drum. SQL ist halt für den Moment etwas sperriger, wenn mans nicht gewohnt ist.
Da kommst du aber kaum drum herum, bzw. du solltest es kennen. Entwickler-Grundwissen.
- Zeitstempel: PHPs time() gibt es ja bei SQL nicht, UNIX_TIME/TIMESTAMP hat ja ein anderes Format. Nehm ich dann für time() aber BIGINT oder VARCHAR?
Du verwendest den von der DB angebotenen Datentypen für Zeitpunkte, und wandelst, sofern der Bedarf besteht, im SELECT in die passende Ausgabeform, bzw. rückwärts beim Schreibzugriff aus dieser Form. In der Regel haben Datenbanken für beide Richtungen Transformationsfunktionen.
- eine URL, ist es schlau die mit VARCHAR(30) zu beschränken? Oder raubt VARCHAR keinen Platz, wenn es nicht voll ausgenutzt wird?
URLs können länger als 30 Zeichen werden - sollen die abgeschnitten werden? VARCHAR belegt in der DB soviel Speicher, wie Zeichen in der Spalte stehen (plus ein festes Offset - siehe DB-Doku). Der einzige Grund, warum man VARCHAR-Felder meiden würde, wäre Performance. Wenn die DB-Tabelle nur aus Datentypen besteht, die feste Feldlängen haben, kann die Position der einzelnen Datensätze evtl. leichter berechnet werden.
- Felder hinzufügen mit ALTER TABLE ist wohl kein Problem?
Sowas ist im Prinzip richtig, aber es sollte nur passieren, wenn sich die Applikation verändert - nicht nur die Daten an sich.
- Den Typ BOOLEAN gibt es nicht? Nehm ich lieber CHAR(1) mit 0 und 1 oder hab ich was übersehen? Wie speicher ich denn on/off - Werte gescheit?
CHAR(1) mit den Werten '0' und '1' ist eine gültige Alternative zu BOOLEAN.
- Sven Rautenberg