Wann welches Tabellenformat

Wann sollte man eigentlich
Berkeley DB
MyISAM
InnoDB

verwenden.
Bzw wo liegen die Spezialgebiete vor so wie Nachteile der Einzelnen.

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Du hast eine wichtige vergessen: Blackhole. Diese sollte man bei hohen
Ähmm ok die habe ich auf keinen meiner MySQL Server zur Verfügung...
braucht das ein spezielles Modul?

Und für weh ist es eigentlich interessant hohe Speicherraten zu haben..
Mir kackt der SQL Server höchstens ab, wenn der mit den Abfragen nicht
mehr nach kommt.

Re: Wann welches Tabellenformat

Heiko (GreenRover) Henning schrieb:
> Andreas Kretschmer schrieb:
>> Du hast eine wichtige vergessen: Blackhole. Diese sollte man bei hohen
> Ähmm ok die habe ich auf keinen meiner MySQL Server zur Verfügung...
> braucht das ein spezielles Modul?
>
> Und für weh ist es eigentlich interessant hohe Speicherraten zu haben..
> Mir kackt der SQL Server höchstens ab, wenn der mit den Abfragen nicht
> mehr nach kommt.

Der Link von Andreas gibt dazu Auskunft... :-)

Damit deine ursprüngliche Frage nicht vergessen geht - auch darüber
gibts im Manual einiges zu lesen:
http://dev.mysql.com/doc/refman/4.1/en/storage-engines.html

--
Markus

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Berkeley DB
gar nicht

> InnoDB
wenn man die Features braucht

> MyISAM
sonst bzw. wenn man die Features braucht.

außerdem fehlen noch

MERGE
MEMORY
ARCHIVE
CSV und
FEDERATED


XL

Re: Wann welches Tabellenformat

Hi Heiko

Heiko (GreenRover) Henning wrote:
> Wann sollte man eigentlich
> Berkeley DB
> MyISAM
> InnoDB
> verwenden.
> Bzw wo liegen die Spezialgebiete vor so wie Nachteile der Einzelnen.

RTM: Choosing a Storage Engine
http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosi ng.html

HTH, Johannes

Re: Wann welches Tabellenformat

Johannes Vogel schrieb:
> RTM: Choosing a Storage Engine
> http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosi ng.html
Danke, ich bin aber mehr auf Infos scharf, welches System für welche
Aufgabe.
Also Aplication, welche Lese / Schreib / Update im bestimmten Verhältnis
hat...

Das heißt, ich hoffe mal, das ich mit MyISAM mit ca aufkommen von
500 / 2 / 1
die richtige Wahl getroffen?

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Ohne zu wissen, was welche Features Du verzichten kannst, kann man diese
> Frage kaum beantworten.

Brauche zwingend:
Full-text search indexes
Index caches
Query cache support
Und bestehen bleiben der Daten auch bei Server Neustart (also kein memory)

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Naja, wenn man auf Transaktionen und referentielle Integrität verzichten
> kann, dann sind die Daten offensichtlich sonderlich wichtig.
Ich vermute jetzt mal das du das sarkastisch gemeint hast.
Dazu kann ich nur sagen, wieso muss das den unbedingt die DB übernehmen.
Wenn man sauber programmiert, ist die Integrität der Daten doch gegen..
Was macht es da aus, ob die DB Fremdschlüssel unterstützt oder nicht?

PS die meisten Daten die in einer Datenbank liegen sind "wichtig".

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Brauche zwingend:
> Full-text search indexes

Wenn Du Full-Text Indexes benoetigst und nur MyISAM-Tabellen diese
unterstuetzen (Stand: 5.0), hat sich doch eigentlich die
Tabellentypsucherei schon erledigt?!

Re: Wann welches Tabellenformat

Hallo,

"Heiko (GreenRover) Henning" wrote:
> Andreas Kretschmer schrieb:
>> Naja, wenn man auf Transaktionen und referentielle Integrität verzichten
>> kann, dann sind die Daten offensichtlich sonderlich wichtig.
> Ich vermute jetzt mal das du das sarkastisch gemeint hast.
> Dazu kann ich nur sagen, wieso muss das den unbedingt die DB übernehmen.
> Wenn man sauber programmiert, ist die Integrität der Daten doch gegen..
> Was macht es da aus, ob die DB Fremdschlüssel unterstützt oder nicht?

klar, schöne Antwort.
Du hast also Möglichkeiten in der Datenbank (ok, in einer richtigen Datenbank),
die genau das zur Verfügung stellt, du jedoch erfindest das Rad gerne neu.

Btw, zeige mir doch mal auf, was du in folgender Situation machst:

- du hast 2 Tabellen, die untereinander in Beziehung stehen
- du trägst einen Wert in die erste Tabelle ein
- du möchtest einen Wert in die zweite Tabelle eintragen, aber:
- Zwischendurch gibt es ein Problem (SQL Fehler, DB weg, Netzwerkproblem)

Was machst du jetzt? Lässt du die erste Tabelle in dem Zustand?


> PS die meisten Daten die in einer Datenbank liegen sind "wichtig".

Dann behandle sie auch so!


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

Andreas Scherbaum schrieb:
> - du hast 2 Tabellen, die untereinander in Beziehung stehen
> - du trägst einen Wert in die erste Tabelle ein
> - du möchtest einen Wert in die zweite Tabelle eintragen, aber:
> - Zwischendurch gibt es ein Problem (SQL Fehler, DB weg, Netzwerkproblem)
Ähm solange ich keine insert id von tab 1 zurück bekommen kann ich doch
eh nichts in tab 2 schmeissen...

also ist das prog so nett und probiert es nochmal oder schmeißt dem User
einem Fehler..

Und wie würdest du das bitte schön lösen?
Ein Query der die Daten in beide tags legt?

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Heiko (GreenRover) Henning schrieb:

> Brauche zwingend:
> Full-text search indexes

Dann liefert Dir die in diesem Thread bereits genannte Adresse=20
http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosi ng.html
eine eindeutige Antwort und die weitere Fragerei ist unter=20
Zugrundelegung Deines spezifizierten Anforderungsprofil sinnfrei.

Full-text-Search Indexes sind ein Ausschlusskriterium für alle Storages=
=20
Engines außer MyISAM.

Guido

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> In einer Transaktion. Die klappt entweder vollständig oder gar nicht,
> aber nicht 'nur ein wenig, vielleicht, bei gutem Wetter'.
Ja, das ist klar..
Aber wenn du 2 tabs hast, hast ja auch 2 Query`s ?!
Also wenn der erste Query nicht funktioniert, weist du ja das ein Fehler
vorliegt und führst nicht noch den 2ten aus.

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Nimm eine Bank und mache eine Überweisung. Du bist am Automat und willst
> eine Rechnung bezahlen. Zuerst werden die 1000 EUR von Deinem Konto
> abgebucht. Das klappt. Nun kommt der Bagger zum Einsatz: er kappt das
> Kabel. 2 Wochen später bekommst Du die Mahnung plus Verzugszinsen. Das
> Geld ist weg. Schade einklich...
Und was würde nun die referenzielle Integrität daran ändern?

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Nix. Das ist wieder was anderes.

Du, sorry dann verstehe ich nicht, was du mir mit dem Beispiel sagen willst?
Das man bei solch heiklen Transaktionen eh nicht vom Terminal aus
handelt sondern von einem sicherenZentraserver (mit "baggerschutz"
sollte klar sein.

Aber wo liegen den die Vorteile des Fremdschlüssels bzw einer DBMS mit
Fremschlüsselunterstüzung. Wo machen Sie es leichter / sicherer.

Re: Wann welches Tabellenformat

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

Andreas Kretschmer schrieb:
> Und auch dafür, daß es nun knallt:
>
> test=*# insert into bestellung (kunde, datum) values (100, current_date);
> ERROR: insert or update on table "bestellung" violates foreign key constraint "bestellung_kunde_fkey"
> DETAIL: Key (kunde)=(100) is not present in table "kunden".
Ähmm so nun lass den Kunden 100 aber dummerweise mal existieren...
Was nun du hast weil du dich ganz auf die DB verlassen hast eine falsche
Verknüpfung gesetzt (dem Kunden eine Bestellung zu geordnet, die er nie
getätigt hat)
Also wohl oder übel, musst du alles vorher überprüfen oder dich drauf
verlassen das deine Applikation so etwas nicht zulässt.

Wo du leider recht hast, das das mit dem Rollback extrem praktisch ist,
wenn du eine instabile Verbindung zum DB System hast.

Aber da habe ich an sich das Glück, das ich PHP Progger bin und mich
darauf verlassen kann, das ich entweder eine Verbindung habe oder nicht
(Socket).

Re: Wann welches Tabellenformat

begin "Heiko (GreenRover) Henning" schrieb:
> Andreas Kretschmer schrieb:
>> Und auch dafür, daß es nun knallt:
>>
>> test=*# insert into bestellung (kunde, datum) values (100, current_date);
>> ERROR: insert or update on table "bestellung" violates foreign key constraint "bestellung_kunde_fkey"
>> DETAIL: Key (kunde)=(100) is not present in table "kunden".
> Ähmm so nun lass den Kunden 100 aber dummerweise mal existieren...
> Was nun du hast weil du dich ganz auf die DB verlassen hast eine falsche
> Verknüpfung gesetzt (dem Kunden eine Bestellung zu geordnet, die er nie
> getätigt hat)

Nein.


> Also wohl oder übel, musst du alles vorher überprüfen oder dich drauf
> verlassen das deine Applikation so etwas nicht zulässt.

Die DB verhindert solchen Unfug. Aber es ist wohl wenig zielführend, in
einem MySQL-Umfeld über RI zu diskutieren, schon klar.


> Aber da habe ich an sich das Glück, das ich PHP Progger bin und mich
> darauf verlassen kann, das ich entweder eine Verbindung habe oder nicht
> (Socket).

*seufz*


end, EOD
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Andreas Kretschmer schrieb:
>> In einer Transaktion. Die klappt entweder vollständig oder gar nicht,
>> aber nicht 'nur ein wenig, vielleicht, bei gutem Wetter'.
> Ja, das ist klar..
> Aber wenn du 2 tabs hast, hast ja auch 2 Query`s ?!
> Also wenn der erste Query nicht funktioniert, weist du ja das ein Fehler
> vorliegt und führst nicht noch den 2ten aus.

Richtig, aber unter Umständen sind die Daten des ersten Queries schon
geändert, was machst du dann? Datensatz wieder löschen? Geht vielleicht
nicht, wenn die DB weg ist -> inkonsistente Daten.

Kannst du immer davon ausgehen, das jede Änderung deiner Daten in
sich atomar ist und den Rest nicht beeinflussen soll/darf?

Fragen über Fragen ...

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Andreas Kretschmer schrieb:
>> Nimm eine Bank und mache eine Überweisung. Du bist am Automat und willst
>> eine Rechnung bezahlen. Zuerst werden die 1000 EUR von Deinem Konto
>> abgebucht. Das klappt. Nun kommt der Bagger zum Einsatz: er kappt das
>> Kabel. 2 Wochen später bekommst Du die Mahnung plus Verzugszinsen. Das
>> Geld ist weg. Schade einklich...
> Und was würde nun die referenzielle Integrität daran ändern?

Die referentielle Integrität nichts, aber die Transaktion schon.
Die wird erst abgeschlossen, wenn dein Geld beim Empfänger auf dem
Konto angekommen ist. Jeder Fehler zwischendurch gibt dir dein Geld
zurück.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
>
> Du, sorry dann verstehe ich nicht, was du mir mit dem Beispiel sagen willst?
> Das man bei solch heiklen Transaktionen eh nicht vom Terminal aus
> handelt sondern von einem sicherenZentraserver (mit "baggerschutz"
> sollte klar sein.

Du möchtest mir gerade bitte mal die Bank zeigen, die inklusive ihrer
Aussenanbindungen zum empfangenen Institut Bagger- Erdbeben- und
Katastrophensicher ist.

Gibts nicht, fragst du dich? Recht hast du.
Aus genau dem Grund wurden auch Mittel und Möglichkeiten geschaffen,
mit solchen Situationen umzugehen. Nutz sie einfach, wenn dir deine
Daten lieb sind.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Andreas Kretschmer schrieb:
>> Und auch dafür, daß es nun knallt:
>>
>> test=*# insert into bestellung (kunde, datum) values (100, current_date);
>> ERROR: insert or update on table "bestellung" violates foreign key constraint "bestellung_kunde_fkey"
>> DETAIL: Key (kunde)=(100) is not present in table "kunden".
> Ähmm so nun lass den Kunden 100 aber dummerweise mal existieren...
> Was nun du hast weil du dich ganz auf die DB verlassen hast eine falsche
> Verknüpfung gesetzt (dem Kunden eine Bestellung zu geordnet, die er nie
> getätigt hat)

Du verwechselst hier Systemfehler mit Applikationfehlern.

Wenn deine Applikation einen Kunden einfügen möchte, der nicht existiert,
dann weigert sich die DB zurecht. Wenn deine Applikation den falschen
auswählt, kann das die Datenbank nie wissen, woher auch.

Aber wenn dir Fehler beim Programmieren unterlaufen, wenn Datenbestände
in der Zwischenzeit anderweitig geändert wurden (Kunde gelöscht z.B.)
oder welche Fehler sonst noch denkbar sind: in all diesen Fällen sorgt
RI dafür, das deine Daten weiterhin konsistent sind und du den Fehler
sofort gemeldet bekommst.


> Wo du leider recht hast, das das mit dem Rollback extrem praktisch ist,
> wenn du eine instabile Verbindung zum DB System hast.

Leider?


> Aber da habe ich an sich das Glück, das ich PHP Progger bin und mich
> darauf verlassen kann, das ich entweder eine Verbindung habe oder nicht
> (Socket).

Träumer, wach auf. Sorry, so viel Gesülze habe ich schon lange nicht
mehr gehört. Du hast dir kein bischen Gedanken gemacht, was mit deinen
ach so wichtigen Daten bei einem Fehler an egal welcher Stelle passiert.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

Andreas Scherbaum schrieb:
> Fragen über Fragen ...
Ja leider schon...

Aber anscheinend tut ihr beiden Andrease kein MySQL zu nutzen?
Was dann?

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Andreas Scherbaum schrieb:
>> Fragen über Fragen ...
> Ja leider schon...
>
> Aber anscheinend tut ihr beiden Andrease kein MySQL zu nutzen?
> Was dann?

Dann gehts unseren Daten gut, was sonst?

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

"Heiko (GreenRover) Henning" wrote:
> Andreas Scherbaum schrieb:
>> Fragen über Fragen ...
> Ja leider schon...
>
> Aber anscheinend tut ihr beiden Andrease kein MySQL zu nutzen?

Das sind zwei PostgreSQL Trolle.

Re: Wann welches Tabellenformat

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Wann welches Tabellenformat

Axel Schwenke wrote:
> "Heiko (GreenRover) Henning" wrote:
>> Andreas Scherbaum schrieb:
>>> Fragen über Fragen ...
>> Ja leider schon...
>>
>> Aber anscheinend tut ihr beiden Andrease kein MySQL zu nutzen?
>
> Das sind zwei PostgreSQL Trolle.

Schön, wenn du schon pauschalisieren möchtest, zeige mir, wo ich
auf PG verwiesen habe? Es stimmt schon, das ich die Software nutze,
du kannst dich hier jedoch mal davontrollen, wenn wir über die
(Un)Sicherheit der Daten des OP sprechen.

All das, worüber wir hier gesprochen haben, ist (mittlerweile)
auch mit Mysql möglich, nur müsste man es halt nutzen. Als
Ergebnis bleiben dann halt wieder ganz wenige Tabellentypen übrig.
Ist die Frage, was einem Datensicherheit und Datenkonsistenz so
wert ist ...


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Wann welches Tabellenformat

>> Aber da habe ich an sich das Glück, das ich PHP Progger bin und mich
>> darauf verlassen kann, das ich entweder eine Verbindung habe oder nicht
>> (Socket).
>
> Träumer, wach auf. Sorry, so viel Gesülze habe ich schon lange nicht
> mehr gehört. Du hast dir kein bischen Gedanken gemacht, was mit deinen
> ach so wichtigen Daten bei einem Fehler an egal welcher Stelle passiert.

Gaaanz ruhig, warum machst du dir da denn überhaupt Gedanken?

Er schreibt doch selber, dass er ein "Progger" ist ;-)

Dieter

Re: Wann welches Tabellenformat

Dieter Noeth wrote:
>>> Aber da habe ich an sich das Glück, das ich PHP Progger bin und mich
>>> darauf verlassen kann, das ich entweder eine Verbindung habe oder nicht
>>> (Socket).
>>
>> Träumer, wach auf. Sorry, so viel Gesülze habe ich schon lange nicht
>> mehr gehört. Du hast dir kein bischen Gedanken gemacht, was mit deinen
>> ach so wichtigen Daten bei einem Fehler an egal welcher Stelle passiert.
>
> Gaaanz ruhig, warum machst du dir da denn überhaupt Gedanken?
>
> Er schreibt doch selber, dass er ein "Progger" ist ;-)

Stimmt.


Danke ;-)

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)