max. Anzahl Felder erreicht - was nun?

[mschaefer]

Moin, moin,

also zunächst mal ist mir das Problem bestens Vertraut, denn ich habe des öfteren mit elektronischen Fragebögen zutun und da kommt es schon mal vor, das einer mehr als 255 Fragen / Felder hat. Also es ist nichtmal was Komplexes. Man kann das natürlich Aufteilen, wobei 1:1 Beziehungen verwendet werden.

Meist ist das Problem nur bei der Basistabelle. Die darauf abgesetzten SQL´s haben üblicherweise nur eine Hand voll Felder, je nachdem was gerade gebraucht wird.

Grüße // Martin

[hoika]

Hallo,

warum soll ein Fragebogen nicht aufgeteilt werden?

Tabelle Kopf
Id Integer
Befragter ..
Datum usw.

Tabelle Fragen
Id Integer
KopfId Integer ref auf Kopf.Id
FrageNo
Antwort



Heiko

[DeddyH]

Ich würde das auch als 1:n-Relation aufbauen. Sollten das genormte Fragen sein, die in verschiedenen Fragebögen auftauchen können, könnte ich mir auch eine m:n-Relation vorstellen. Aber das ganze quasi "flat-file" aufzubauen halte ich für den falschen Weg.

[edit] Bachstuben verwechselt [/edit]

[Hansa]

Zitat:

Zitat von Phoenix

Im Im Normalfall kommt man mit maximal 20 Spalten gut aus.

*hust* ãhm, ist spass oder ? :mrgreen:

[mkinzler]

Zitat:

*hust* ãhm, ist spass oder ? Mr. Green

:stupid: Nein

[hoika]

Hallo,

kommen wir doch noch mal zum Ausgangspunkt.

Noch mal die Frage:
Warum brauchst du so viel Felder ?


Heiko

[mschaefer]

Warum fragen sind schon bei DreiKäsehoch nicht wirklcih zu beantworten. Letzlich sind Beziehungen dann wichtig, wenn Eigenschaften Felder einer Haupteinheit mehrfach zugeordnet werden können müssen. Wenn ich keine 1:n Beziehung brauche, dann kann man es auch einfach mit der großen Feldanzahl machen.

Zum Beispiel brauch tman dann beim Import von csv-Dateien nur eine Tabelle zu bearbeiten. Warum auf Warumfrage:
Warum soll da umbedingt eine mehrfach Beziehung rein, wenn die im Programm nicht verwendet wird ?

Viele Grüße in die Runde // Martin




PS: Hoika hat das im 2 folgenden Beitrag zussamengefasst, da kann ich gut mit leben...

Letzlich hängt das von der geforderten Geschwindigkeit und der Haltbarkeit der Datenbank ab. Ich habe so einige Projekte gehabt, wo absehbar war und ist, dass die Lebensdauer maximal 6 Monate bis 2 Jahre nicht übersteigt. Gerade Konverterprojekte sind so eine Sache. Da ist die Entwicklungsgeschwindigkeit weit weit eher der Kostenfaktor. Und da man mit Excel 2007 auch mal eben 5000 Felder in eine SQL-Datenbank schieben kann, neige ich manchmal dazu die Eingangstabellen nicht aufzuteilen.
Das sind allerdings keine dauerhaften Arbeitstabellen....

So long // Martin

[mkinzler]

das ist aber nur ein Aspekt der Normalisierung. Ein anderer ist es zu schauen, welche Daten wirklich gebraucht werden. Wenn man sieht das im Großen-und.Ganzen immer nur 5 Felder benötigt werden und die anderen Ab-und-Zu, dann macht eine Splittung in 1:1 Einheiten Sinn.
Aber im Normalfall sind die wenigsten Spalten voll vom PK abhängig

[hoika]

Hallo,

bei einer IBExpert-Veranstaltung hat Holger Klemt mal zu Firebird erzählt.

Kunde hatte Performance-Probleme.
Das Auslagern nicht sehr oft verwendeter Felder in eine eigenständige Tabelle (1:1)
brachte die Lösung.

Hier im Fall des Fragestellers geht es darum, dass er Access und mehr als 255 Felder braucht.
Da Access das nicht kann, gibt es Lösungsvorschläge und einer davon ist halt die Normalisierung.


Heiko

[khh]

Zitat:

Zitat von mkinzler

Zitat:

*hust* ãhm, ist spass oder ? Mr. Green

:stupid: Nein

Sollte man generell nicht an 20 Feldern festmachen.
Eine Kundentabelle hat auch schnell mal 30 Felder erreicht und ist dennoch in der 3ten Normalform.


Gruss KH