Parameter unter Firedac

[Sir Rufo]

Was entspricht nicht der Normalisierung? Die GUID an dem Bild zu speichern?

Wie kommst du da drauf? Den eindeutigen Pfad zu der Bilddatei bekommst du doch nur über die GUID des Ordners und dem relativen Pfad zu der Datei. Als gehören diese Informationen auch zu dem Datensatz.

[Delbor]

Hi Sir Rufo

Zum einen schreien 444 Datensaetze mit einem Feld, das überall den gleichen Wert hat, nach einer eigenen Tabelle.

Eine Adresstabelle, enthält ja in der Regel aauch eine eigene Strassentabelle, in der jede Strasse einmal aufgeführt ist, aber mit beliebig vielen Personen verknüpft ist. Dabei gibts hier noch die Besonderheit, dass in vielen Orten je eine =Post- und eine Bahnhofstrasse vorhanden ist. Genau genomen müssten solche Strassen (auch Marktstrasse uund -Gasse etc) nur gerade in einer Strassentabelle vorhanden sein, könnten aber mit beliebigen Personen und fast beliebigen Orten verknüpft werden.

Klar, diese 200KB sind nicht viel und das schreit von daher seinerseits nach Brechen der Normalisierung - was ja je nach dem auch mal sinnvoll sein kann.

Zitat:

Den eindeutigen Pfad zu der Bilddatei bekommst du doch nur über die GUID des Ordners und dem relativen Pfad zu der Datei.

Vorerst ist die DB darauf ausgelegt, den vollen Pfad zu speichern. Okay - Hier nur den relativen Pfad - Ordner- und Dateinamen - zu speichern und den Rest des Pfades Aufgrund der GUID zu ermitteln würde den Speicherbedarf aufgrund des nur relativen Pfades wieder etwas verringern.

Ich hab in den letzten Tagen mal ein kleines Beispielprogramm mit TClientdataset nachgebaut, einfach, um zu sehen, was dabei wirklich raussschaut. Der Nachteil ist, dass die Fotos im Explorer nicht mehr als solche erkennbar sind. Der Vorteil wohl, dass sie gerade dadurch wohl etwas besser vor versehentlichem löschen geschützt sind.

Gruss
Delbor

[DeddyH]

Die GUID ist doch als Schlüssel gedacht, von daher kann sie natürlich beliebig oft vorkommen. Wozu also noch eine weitere Tabelle?

[Delbor]

Hi zusammen

Zitat:

Die GUID ist doch als Schlüssel gedacht, von daher kann sie natürlich beliebig oft vorkommen. Wozu also noch eine weitere Tabelle?

Stimmt auch wieder - der Datensatz bräuchte ein Schlüsselfeld zur Guidtabelle und diese einen PrimärIndex. Damit wäre bei einer Abfrage ein zusätzliches Schlüsselpaar zu verarbeiten.

Gruss
Delbor