Sven Rautenberg: ein Grund, SQLite nicht zu nutzen

Beitrag lesen

Moin!

»» Da aber üblicherweise in DB-Abfragen doch wieder Zeitkomponenten reinkommen, die man eventuell nicht vorberechnen kann, besteht die Tendenz, Zeitberechnung AUCH in der DB zu machen. Dann aber sollte man sie AUSSCHLIESSLICH in der DB machen, nicht mehr in PHP.

Auf der anderen Seite sind SQL-Abfragen, die dynamisch mit Funktionsergebnissen rechnen, wie sie naturgemäß von Funktionen wie NOW() zurückgegeben werden, immer ein Kandidat für schlechtere Performance, weil aufgrund des dynamischen Funktionsergebnisses der Query-Cache vermutlich nicht genutzt werden kann. Abfragen mit konkret statischem Datum, selbst wenn es vom abfragenden Skript nur dynamisch vorberechnet ist, aber dann statisch im Query landet, lassen sich, sofern die betreffenden Tabellen nicht verändert werden, aus dem Cache bedienen, was erheblich die Performance steigert.

Diese Überlegungen treffen aber natürlich nur zu, wenn man wirklich ein DB-Performanceproblem hat. Wenn man vor der Wahl steht, irgendein Eigengebräu als Speicher zu verwenden, oder eine Datenbank, dann steht man vermutlich noch nicht vor einer Performancefrage.

... und dann wären wir an einem Punkt der Ausgangsfragestellung angelangt:
dies wäre ein Grund, SQLite nicht zu benutzen, so wie es auch im Handbuch steht:

<zitat>
    "In order to achieve simplicity, SQLite has had to sacrifice other
    characteristics that some people find useful, such as high concurrency,
    fine-grained access control, a rich set of built-in functions, stored
    procedures, esoteric SQL language features, XML and/or Java extensions,
    tera- or peta-byte scalability, and so forth. If you need some of these
    features and do not mind the added complexity that they bring, then
    SQLite is probably not the database for you.
    [...]
    Another way to look at SQLite is this: SQLite is not designed to replace
    Oracle. It is designed to replace fopen()."
</zitat>

Wenn ich die Wahl hätte, ein Eigengewächs mit fopen() zu nutzen, oder SQLite, dann fiele meine Wahl vermutlich oftmals auf SQLite.

Bestünde die Wahl zwischen SQLite und MySQL, wählte ich vermutlich MySQL.

:)

- Sven Rautenberg

0 43

sqlite - gibts gründe, das nicht zu nutzen?

frankx
  • datenbank
  1. 1
    dedlfix
    1. 0
      frankx
      1. 0
        frankx
        1. 0
          dedlfix
          1. 0
            frankx
          2. 0

            Zend_DB - weder toll noch un-toll, u.U. einfach praktisch

            frankx
            1. 1
              dedlfix
              1. 0
                frankx
                1. 0
                  dedlfix
                  1. 0
                    frankx
      2. 0
        dedlfix
        1. 0
          frankx
          1. 0
            dedlfix
  2. 0

    sqlite vs. serialisiertes Array

    frankx
    1. 0
      dedlfix
      1. 0
        frankx
        1. 1
          Ilja
          1. 0
            frankx
    2. 0
      Sven Rautenberg
      1. 0

        sqlite vs. serialisiertes Array - welcher Vartyp für welche Vars

        frankx
        1. 0
          Sven Rautenberg
          1. 0
            frankx
            1. 1
              Sven Rautenberg
              1. 0
                frankx
                1. 0
                  Sven Rautenberg
                  1. 0

                    ein Grund, SQLite nicht zu nutzen

                    Vinzenz Mai
                    1. 0
                      frankx
                    2. 0
                      Sven Rautenberg
                      1. 0
                        frankx
                        1. 0
                          Vinzenz Mai
                          1. 0
                            ChrisB
                        2. 1
                          Sven Rautenberg
                          1. 0
                            frankx
                            1. 0
                              Sven Rautenberg
                              1. 0
                                frankx
        2. 1
          dedlfix
          1. 0
            frankx
            1. 0
              dedlfix
              1. 0
                frankx
                1. 0
                  dedlfix
          2. 0

            ALTER TABLE = schlechtes Design - serialisierte PHP Daten

            frankx
            1. 0
              dedlfix