AW: AW: AW: Dateninhalt bzw. dynamische Felder in MySQL

[Sebastian Tobias Mendel genannt Mendelsohn]

Andreas Müller wrote:

> Hallo Sebastian,
> irgendwie drängt sich mir der Eindruck auf das du so leicht aus der Oracle
> Ecke kommst - kann mich aber auch irren.

nö


>>ich meine bei einer Software für eine kleine Bau-Klitsche ist das wohl
>>kein Problem, da geht das auch mit einem BLOB-Feld schnell, aber bei
>>größeren Firmen und dementsprechender Anzahl an Datensätzen ...
>>ich beziehe mich hier vor allem auf die Suche!
> 
> 
> Sorry wenn ich dich da korrigieren muss aber eine Datenbank ist nicht in
> erste Linie zum Suchen von Daten da. Sonst würden die Suchfunktionen in den
> Datenbanken wohl wesentlich besser sein als sie sind. Eine Datenbank
> verwaltet Daten und gibt Möglichkeiten auf diese Daten zuzugreifen. Das was
> du als "Suchen" bezeichnest kann der Zugriff auf einen Datensatz per Primary
> Key sein aber auch die "Volltextsuche" ala like '%begriff%'
> Das sind 4GL technisch das gleiche denn ich sage nur was ich haben will und
> nicht wie der Server das tun soll. Dabei brauche ich mir solange keinen Kopf
> zu machen wie das ein Datenbankserver dann umsetzt solange ich mich schön an
> relationale Prinzipien halte. Breche ich etwas aus dem 0815 Schema aus dann
> muss ich mir eben mal überlegen wie man sowas geschickt bauen kann.

ja und? sag ich doch, zum Suchen nach Daten ...

ich formuliere eine Anfrage an den Server mit bestimmten Parametern und 
der Server sucht alle Datensätze nach meinen Vorgaben durch und liefert 
mir das Ergebnis!

... denn auch wenn ich ihm nicht sage wie er es machen soll (obwohl ich 
dies eigentlich schon tue, durch das Design der Datenbank und der 
Erfassung der Daten) ist es trotzdem eine Suche, nix anderes, jede 
Anfrage ist eine Suche nach bestimmten Datensätzen die bestimmte 
Kriterien erfüllen! eine Suche!


> Eine Suche in einer Datenbank ist immer so gut wie man sie macht. Daten nach
> denen ich oft suchen muss würde ich definitiv nicht als dynamische Felder
> machen. Siehe meinem bereits geposteten Grundsatz für dynamische Felder.
> Genauso ist es nicht sinnvoll _alle_ Felder einer Entität (weil von
> Datensatz kann man dann nicht mehr sprechen) dynamisch zu machen. Zumindest
> nicht in einem RDBMS. Aber alles dazwischen kann sehr sinnvoll und nützlich
> sein.

hab ich doch gesagt, oder auf jeden Fall nichts andereslautendes


>>und vor allem gestaltet sich das Problem bei dir ja auch ganz anders, du
>>hast ja bereits vordefinierte Felder, welche wohl den größten Teil der
>>zu speichernden Daten abdecken, und deine Dynamischen Felder entsprechen
>>in etwa den normalen 'Notizen'-Feldern (o.ä.) welche auch als BLOB (wie
>>eigentlich jedes größere Text-Feld) in einer extra-Tabelle liegen!
> 
> So und das kann ich echt nicht nachvollziehen. Okay bei Oracle
> Programmierern kenn ich sowas denn Oracle konnte bis zur Version 8.1 maximal
> ein Bob Feld pro Tabelle etc. Auch heute sind Blob oder Clob Felder unter
> Oracle nicht wirklich prickelnd.
> Ich sehe an sich überhaupt keinen Grund Blob Felder in eine extra Tabelle zu
> legen. Vorteile kann ich dabei absolut keine erkennen - eher Nachteile.

diese Äußerung verwundert mich, wenn man hier schon mitredet sollte man 
doch wenigstens MySQL kennen, zumindest das Handbuch!

es hat einen ganz einfachen Grund: Geschwindigkeit!

da es oft so ist das die Langen Textfelder oder BLOBS (wesentlich) 
seltener gebraucht werden als die restlichen Felder, sie blähen die 
Datei in der die Tabelle abgelegt ist auf, und erhöhen somit die Suche 
nach Daten und vor allem das auslesen der Datensätze, selbst wenn MySQL 
den Index nimmt zum suchen.

außerdem ist MySQL mit rein Statischen Tabellenbreiten nun mal schneller 
(laut Handbuch) und Langtexte/BLOBS sind nunmal dynamisch

http://www.mysql.com/doc/en/Data_size.html

-- 
Sebastian Mendel (www.sebastianmendel.de)

*www.warzonez.de* | www.tekkno4u.de | www.nofetish.com

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql