Daten und Struktur trennen

[Marco]

Hallo zusammen,

es geht um eine MySQL-Datenbank, die Zugangsdaten speichern soll. Dabei könnte man jetzt sicher für "Normalfälle" wie E-Mail, FTP usw. eine geeignete Struktur konzipieren. Mir schwebt da allerdings etwas anderes vor.

Ich möchte gern die Struktur von den Daten trennen. Ganz trivial denke ich über eine Struktur-Tabelle und eine Daten-Tabelle nach. Macht sowas Sinn? Gibt es vielleicht schon ähnliche oder bessere Ansätze? Der Grund dafür ist, daß ich flexibel bleiben will, falls mal ein Feld hinzukommt. Das müßte ich dann der Struktur-Tabelle hinzufügen und die Daten-Tabelle würde sich lediglich auf einen Spaltennamen der Struktur-Tabelle beziehen.

Hoffentlich konnte ich meine Gedanken einigermaßen gut beschreiben.

Viele Grüße
Marco

[Tom]

Hello,

Ich möchte gern die Struktur von den Daten trennen. Ganz trivial denke ich über eine Struktur-Tabelle und eine Daten-Tabelle nach. Macht sowas Sinn? Gibt es vielleicht schon ähnliche oder bessere Ansätze? Der Grund dafür ist, daß ich flexibel bleiben will, falls mal ein Feld hinzukommt. Das müßte ich dann der Struktur-Tabelle hinzufügen und die Daten-Tabelle würde sich lediglich auf einen Spaltennamen der Struktur-Tabelle beziehen.

Meinst Du nicht eher, dass jede Daten-Tabelle einen (oder mehrere) Datensätze in der Strukturdatenbank erhalten soll?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Marco]

Meinst Du nicht eher, dass jede Daten-Tabelle einen (oder mehrere) Datensätze in der Strukturdatenbank erhalten soll?

Hi Tom,

das beantwortet zwar nicht konkret meine Frage, aber trifft zu und so meinte ich es auch. Zu jeder Spalte einer Datentabelle gibt es einen Datensatz in der Strukturtabelle, der den Namen, den Typ und alle sonstigen Informationen enthält.

Viele Grüße
Marco

[Rouven]

Hello,

ein Gedanke, den man natürlich nicht außer Acht lassen darf, ist Performance. Wenn du für jede gesuchte Information erstmal nachschlagen musst, wo du sie überhaupt findest, bzw. zu einer gefundenen Information erstmal rausfinden musst, worum es sich handelt, dann kostet das Laufzeit. Generell ist es aber z.B. für Kontaktinformationen ein nicht ganz unübliches Verfahren mit einer dynamischen Attributstruktur zu arbeiten:

kontakttyp
1 | telefon
2 | mobiltelefon
3 | email

person_kontakt
personid | kontaktid | wert
1        | 1         | 069...
1        | 2         | 0151...

Neben der Performance sollte man auch im Hinterkopf behalten, dass es weitere Klimmzüge braucht um unterschiedliche Datentypen zu verarbeiten. Im obigen Beispiel bist du praktisch gezwungen, alles als Zeichenketten abzulegen. Was, wenn es sich jetzt um Zeichenketten, vermischt mit Zahlen, vermischt mit Datumsangaben handelt? Egal? 3 Spalten und ein zusätzlicher Typindikator?

Am Ende des Tages: Gehst du davon aus, dass du die Flexibilität wirklich wirklich brauchst, dann gehe ruhig auf das dynamische Modell. Brauchst du sie nicht, oder brauchst du nur etwas Flexibilität, dann modelliere alles als "echte" Spalten, was dir jetzt bekannt ist, und sehe eine (zwei) Tabellen für zukünftige Erweiterungen vor.

MfG
Rouven

[Tom]

Hello,

ein Gedanke, den man natürlich nicht außer Acht lassen darf, ist Performance. Wenn du für jede gesuchte Information erstmal nachschlagen musst, wo du sie überhaupt findest, bzw. zu einer gefundenen Information erstmal rausfinden musst, worum es sich handelt, dann kostet das Laufzeit. Generell ist es aber z.B. für Kontaktinformationen ein nicht ganz unübliches Verfahren mit einer dynamischen Attributstruktur zu arbeiten:

kontakttyp
1 | telefon
2 | mobiltelefon
3 | email

person_kontakt
personid | kontaktid | wert
1        | 1         | 069...
1        | 2         | 0151...

2        | 3         | [e-mail]

Spannend wird es erst, wenn Du nun auch noch versuchst, den Variant-Typ der Spalte wert so aufzulösen, dass er wieder in eine typiserte Spalte passt.

Darüber, wie man das mit SQL-Datenbanken machen müsste, denke ich schon länger nach.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Rouven]

Hello,

dazu kenne ich zwei Ansätze:
kontakttyp
1 | telnr | String
2 | email | Mailaddresse
<>| ...   | <Datentyp>

--> du liest in der Typspalte nach, um welche Art von Daten es sich handelt.

• Information ist einmal abgelegt und kann verwendet werden
• Es gibt nach wie vor nur eine Datenspalte

• Die Daten sind als String abgelegt

person_kontakt
personid | kontakttypid | datacolum | stringcol | datecol | numbercol | ...
1          1              stringcol         abc

• Die Informationen sind wirklich in einer Spalte des passenden Datentyps abgelegt -> Suche mit z.B. Datumsfunktionen möglich

• es sind pro Satz etliche Spalten ungenutzt
• es ist sehr aufwändig nach einer unbekannten Information zu suchen, weil diese sich in etlichen Spalten befinden kann

MfG
Rouven

[solkar]

kontakttyp
1 | telefon
2 | mobiltelefon
3 | email

person_kontakt
personid | kontaktid | wert
1        | 1         | 069...
1        | 2         | 0151...

Nach einer Nacht "CORBA_Zurechtbiegen" bin ich nicht z.Zt. vlt. nicht ganz auf der Höhe aber mir will grad nicht einfallen wie man (Ohne Subqueries) eigentlich bei einer solch einer flachen Struktur folgendes Problem

"Finde alle Personen, für die kein EMail-Eintrag existiert"

lösen könnte.

Bei zwei Tabellen würde ich's mit einem LEFT OUTER JOIN von t_person_kontakt nach z.B. t_email e nebst WHERE e.email IS NULL machen (ist das eigentlich die einzige Möglichkeit?) aber wie ginge das eigentlich im obigen Fall?

Irgendwie geht's bestimmt, aber ich seh's grad nicht.

Grüsse

Solkar

[Vinzenz Mai]

Hallo

kontakttyp
1 | telefon
2 | mobiltelefon
3 | email

person_kontakt
personid | kontaktid | wert
1        | 1         | 069...
1        | 2         | 0151...

"Finde alle Personen, für die kein EMail-Eintrag existiert"

Bei zwei Tabellen würde ich's mit einem LEFT OUTER JOIN von t_person_kontakt nach z.B. t_email e nebst WHERE e.email IS NULL machen (ist das eigentlich die einzige Möglichkeit?) aber wie ginge das eigentlich im obigen Fall?

Irgendwie geht's bestimmt, aber ich seh's grad nicht.

Ganz genauso :-) Mit einem LEFT OUTER JOIN:

SELECT  
    p.vorname,  
    p.nachname,  
    ...  
FROM  
    personen p  
LEFT OUTER JOIN  
    person_kontakt pk  
ON  
    p.personid = pk.personid  
AND  
    pk.kontaktid = 3  -- Betrachte nur E-Mail-Adressen  
WHERE  
    pk.wert IS NULL  

Wichtig ist, dass die Bedingung in der JOIN-Bedingung steht - und nicht etwa
in der WHERE-Klausel.

Freundliche Grüße

Vinzenz

[solkar]

Hallo

kontakttyp
1 | telefon
2 | mobiltelefon
3 | email

person_kontakt
personid | kontaktid | wert
1        | 1         | 069...
1        | 2         | 0151...

"Finde alle Personen, für die kein EMail-Eintrag existiert"

Bei zwei Tabellen würde ich's mit einem LEFT OUTER JOIN von t_person_kontakt nach z.B. t_email e nebst WHERE e.email IS NULL machen (ist das eigentlich die einzige Möglichkeit?) aber wie ginge das eigentlich im obigen Fall?

Irgendwie geht's bestimmt, aber ich seh's grad nicht.

Ganz genauso :-) Mit einem LEFT OUTER JOIN:

SELECT

p.vorname,
    p.nachname,
    ...
FROM
    personen p
LEFT OUTER JOIN
    person_kontakt pk
ON
    p.personid = pk.personid
AND
    pk.kontaktid = 3  -- Betrachte nur E-Mail-Adressen
WHERE
    pk.wert IS NULL

>   
> Wichtig ist, dass die Bedingung in der JOIN-Bedingung steht - und nicht etwa  
> in der WHERE-Klausel.  
>   
>   
> Freundliche Grüße  
>   
> Vinzenz  
  
;-)  
  
Ja, ok, person\_kontakt ist m:n zwischen person  
( die aber oben nicht steht!!! sach ich ma zu meiner Ehrenrettung ;)  )  
und kontakttyp.  
  
Ja, ok, ich hätte sehen müssen, dass personid kein PK sein kann..  
  
ja, ok, ich bin ja schon ruhig...  
  
;-)  
  
Danke und schönes WE!  
  
Solkar  
  
  
  
  
  
  
  
  

[Tom]

Hello,

Hoffentlich konnte ich meine Gedanken einigermaßen gut beschreiben.

Im Prinzip wäre dies eine Erweiterung des Imformation Schema

http://dev.mysql.com/doc/refman/5.0/en/information-schema.html

speziell

http://dev.mysql.com/doc/refman/5.0/en/columns-table.html

um Informationen, wie z.B. Display-Eigenschaften für Standard-Views (Browse, Edit, ...), Column-Constraints & -Relations usw.

Also erstmal schauen, was bereits implementiert ist, und dann entscheiden, was noch fehlt und WIE es zusätzlich eingebaut werden könnte.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg