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

[Andreas Müller]

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

> ja und nun zurück zur Frage, welchen Datentyp hat dein Feld
> `address_dyn`.`value` ?

Das hängt von der Art der Implementierung ab und dabei verweise ich auf
meine Antwort auf die Frage. Man kann 1 Feld nehmen oder auch x Felder - pro
Datentyp eins, bei varchar dann varchar(255). Was im übrigen genau soviel
Platz braucht wie ein kleineres varchar-Feld.

> und wozu verwendest du das Feld `field`.`datatyp` ? für die richtige
> Darstellung oder?

Zum einen für die richtige Darstellung, zum anderen für die richtige Ablage
im Value-Feld - ob das nun auswahl des richtigen Feldes (siehe oben) oder
die richtige Inhaltsformatierung ist.

> 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.

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.

> 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.

Gruß,
Andreas


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