max. Anzahl Felder erreicht - was nun?

[Cogito]

Hallo zusammen,

ich habe nun die max. Anzahl an Feldern (255) erreicht, benötige aber eigentlich noch mehr. Hatte hier schon mal jemand das gleiche Problem? Was könnte man tun?

[Bernhard Geyer]

1, Aufteilen in meherer Tabellen welche die gleichen Primärschlüssel haben.
2, Checken ob ein Wechsel auf eine neuere Access-Version dieses Limit immer noch hat
3, Wechsel auf eine vernünftige DB :mrgreen:

[shmia]

4, dein Datenbankdesign ist höchstwahrscheinlich fehlerhaft (nicht vollständig normalisiert)
Ich kenne keine Anwendung für Datenbanken, die das Limit von 255 Feldern wirklich überschreiten würde.

[hoika]

Hallo,

Access 2007

Punkt 2 kannst du also streichen.
Sinnvoll ist ein geändertes DB-Design (Normalisierung).

Eine Frage, wie viele Felder sind im Durchschnitt pro Record belegt ?

Da fällt mir ein:
Unter Paradox hatte ich das Problem damals auch mal.
Lösung war damals 1. (zusätzliche Tabelle).


Was steht denn in der Tabelle drin ?



PS:
Unter Firebird kann man 65535 Felder anlegen.
Trotzdem ist ein select * auf so eine Tabelle
auch in Firebird performancemässig lahm,
wenn viele Felder eh NULL sind.


Heiko

[Cogito]

Zitat:

Zitat von Bernhard Geyer

1, Aufteilen in meherer Tabellen welche die gleichen Primärschlüssel haben.
2, Checken ob ein Wechsel auf eine neuere Access-Version dieses Limit immer noch hat
3, Wechsel auf eine vernünftige DB :mrgreen:

Hätte denn ein MS SQL Server nicht diese Felderbegrenzung? Wie ist die denn da?

[hoika]

Hallo,

dann googlen wir mal

SQL 2000
Columns per base table 1,024

SQL 2005
Columns per base table 1,024

SQL 2008
Columns per nonwide table 1,024
Columns per wide table 30,000

Was auch immer eine "wide table" ist.


Heiko

[Bernhard Geyer]

Zitat:

Zitat von Cogito

Hätte denn ein MS SQL Server nicht diese Felderbegrenzung? Wie ist die denn da?

+ 8060 Byte (!) Grenze pro Datensatz. z.B. 2 * nvarchar zu 100 Zeichen gefüllt ergeben 404 Byte von dieser 8060er Grenze schon verbraucht.

Jedes DMBS hat so seine Grenzen.

[Phoenix]

Zitat:

Zitat von Cogito

Hätte denn ein MS SQL Server nicht diese Felderbegrenzung? Wie ist die denn da?

Das ist die falsche Frage.

Ich habe schon ungeheuer komplexe Anwendungen mit Datenbanken hinten dran gesehen. Im allerschlimmsten Fall hatte da eine Tabelle 40 spalten. Und das sind schon zu viele gewesen. Im Normalfall kommt man mit maximal 20 Spalten gut aus.

Das heisst: Die Datenstrukturen in Deinem konkreten Fall sind aller Wahrscheinlichkeit nach suboptimal.

Wenn Du die Struktur Deiner Daten in Ordnung bringst, dann tut a) auch Dein Access weiterhin und b) dürfte die ganze Angelegenheit mit an Sicherheit grenzender Wahrscheinlichkeit um längen schneller sein. Und in aller Regel ist das dann zusätzlich auch noch einfacher zu erweitern.

Was speicherst Du denn da drin, dann können wir Dir vielleicht ein paar Tipps geben, wie Du Deine Daten besser organisieren kannst.

[hoika]

Hallo Bernhard,

Ich habe nicht pro Datensatz, sondern pro row gelesen.
Ein Record kann sich auch über mehrere Rows hinziehen.
Ist aber begrenzt (siehe Link)

Row Overflow


So genau weiss ich es aber nicht.
Mal den SQL-Express rauskramen und prüfen ...
Aber, ne, ich hab ja Firebird ;)

Aber noch mal zum Fragesteller,
was ist das für eine Tabelle, warum soviele Felder.

Ich rate mal:
Tabelle Personal
Telefon1, Telefon2, Telefon3, Telefon4 ...


Heiko

[Tyrael Y.]

Wie hier schon einige gesagt haben, solltest du die Datenbank "normalisieren"
Schau mal bei Google unter dem Stichwort "3. Normalform"

Ich arbeite oft mit Datenbanken und die Tabelle, die bisher sehr viele Felder hatte,
hatte 12 Felder und das war schon richtig viel.

Mach dir die Welt einfacher in Zukunft und berücksichtige den Vorschlag der "Normalisierung" in Zukunft.
Das wäre die einzig vernünftige Lösung.

[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

[mkinzler]

Kann zwar passieren, lässt sich aber durch konsequente Normalisierung meistens verhindern.
Aber zwischen 20/30 und 255 ist ja noch etwas Luft.

[Hansa]

< 20 Felder geht doch gar nicht. Zumindest nicht im Normalfall <> Normalform. Was soll man denn hier groß abspecken :

Delphi-Quellcode:

Tabelle Kunde

ID
ID_KG, // Kundengruppe
anrede,
name,
strasse,
ort,
Lieferanrede,
Liefername,
Lieferstrasse,
Lieferort,
Tel1,
Tel2,
Fax,
email,
TelPrivat,
www,
bemerkung,
...

Das sind jetzt schon mind. 17 Felder und ab 20 ist schon in separate Tabellen auszulagern ? :gruebel: Und dann mit JOIN TELNUMMERN JOIN ADRDATEN etc. rumhantieren ??? Sofern nicht mal 255 Felder ausreichen, dann lasse ich mir das noch gefallen, aber bei 20 ? :shock: Man muss auch mal die Praxis miteinbeziehen und da gilt immer noch : was zusammengehört, das wird zusammen gespeichert.

[mkinzler]

Zum Beispiel:
-Adresse(n) in eigene Relation (1:n bzw, n:m)
-Kommunikationsadressen in eigene Relation (1:n bzw, n:m)
-wenig benötigte Felder in eigene Realtion (1:1, 1:n oder n:m)
...

[khh]

Zitat:

Zitat von mkinzler

Zum Beispiel:
-Adresse(n) in eigene Relation (1:n bzw, n:m)
-Kommunikationsadressen in eigene Relation (1:n bzw, n:m)
-wenig benötigte Felder in eigene Realtion (1:1, 1:n oder n:m)
...

ja, kann man sicher machen, aber wie speckst du ab wenn die ids der Relationen sich summieren:


KDGRP_ID
PREISGRP_ID
RABATT_ID
SKONTO_ID
LIEFERKOND_ID
..
..
..

nur um mal einige zu nennen.

Gruss Kh

[Hansa]

Habe mir mal die eigenen Tabellen angeguckt. Jede Tabelle hat standardmäßig noch zwei Felder :

SQL-Code:

    ANGELEGT         TIMESTAMP,
    LETZTEAENDERUNG  TIMESTAMP

Damit wären wir bei 19. Wichtig wären noch die Bankdaten und somit die 20-Grenze bereits gesprengt. :zwinker: Meine reale Kunden-Tabelle hat 56 Felder und es wäre sehr sehr mühselig und vor allem fehleranfällig, die auf < 20 Felder zu drücken. Die Felder sind dabei alle wichtig und keineswegs redundant. Wenn ich eine Kunden-Nr. eingebe, dann will ich die zugehörigen Daten sehen, auch notfalls die Fax-Nr. etc. Ich will diese Daten nicht noch mühselig zusammensuchen. Apropos, wie wärs denn mit : pro Feld eine Tabelle ? :mrgreen: @roter Kasten : jup, das gehört auch da rein.

[khh]

Zitat:

Zitat von Hansa

Habe mir mal die eigenen Tabellen angeguckt. Jede Tabelle hat standardmäßig noch zwei Felder :

SQL-Code:

    ANGELEGT         TIMESTAMP,
    LETZTEAENDERUNG  TIMESTAMP

richtig, die beiden Felder gehören ebenso dazu.
ich speichere auch noch den AENDERER mit.

aber trotz allem 255 sind zu viel ;-)

Gruss KH

[p80286]

Hallo alle miteinander,

der "zwanziger Fraktion" sei gesagt,daß es auch Tabellen mit 50 (sinnvollen) Feldern gibt (ohne Telefon1,Telefon2....).
Aber 255 ist wirklich etwas arg heftig.

Der Initiator diese "Glaubenskrieges" scheint nun aber verscheckt zu sein.

Gruß
K-H

[DeddyH]

Solange die Struktur atomar ist, spielt die Anzahl der Felder ja erst einmal keine Rolle, oder täusche ich mich da?

[hoika]

Hallo,

*verschähmt meld*
ich habe hier auch ne Tabelle mit 252 Feldern ...

Dort sind Rechte für Gruppen drin,
pro Recht ein Char(1)-Feld.

Dann war (damals) auch bei Paradox Schkuss
und ich habe es umgestellt.


Heiko

[mschaefer]

:zwinker:

wenn man Daten für lineare Optimierungsmodelle in einer Datenbank hält um dann einfach die Matrix in ein Grid schieben zu können,
kommt man auch recht schnell auf solche Spaltenzahlen. Aber das ist ja schon fast so kurios wie die Rechtetabelle....

Grüße in die Runde // Martin

[alzaimar]

Ich schmeiss mal 'DWH' in die Runde. Dort sind schnell 1000 und mehr Spalten in einer Tabelle. Gut, es kommen auch mal eben einige TB zusammen, sodaß Access, egal in welcher Version hier nur bedingt ein geeigneter Kandidat wäre..

[Phoenix]

Jetzt hackt nicht so auf den 20 rum. ;-)

Ich sagte zum einen im Normalfall. Und zum anderen: Wie viele von Euren Tabellen haben > 20 Spalten? Sind es alle Tabellen oder nur einzelne und der Großteil der Tabellen hat weniger? Ich tippe bei einem guten DB-Design auf letzteres ;-)

[Cogito]

Sorry Leute, ich wollte hier auf gar keinen Fall einen Glaubenskrieg vom zaun brechen. Ich bin auch nicht der tolle DB-Profi, deshalb denke ich auch dass ich hier was falsch gemacht habe, obwohl mir das Thema Normalisierung durchaus bekannt ist. Ich habe jetzt auch den Rat einiger befolgt und weniger wichtige Felder in andere Tabellen ausgelagert. Ich erstelle übrigens eine Fondsdatenbank und es gibt unendlich viele Informationen zu einem Fond, die mit diesem in direktem Zusammenhang stehen.
Vielen Dank an alle!

[DeddyH]

Zitat:

Zitat von Cogito

Sorry Leute, ich wollte hier auf gar keinen Fall einen Glaubenskrieg vom zaun brechen.

Das ist nicht Deine Schuld, das gibt es hier öfter mal ;)

[mschaefer]

Ist es doch auch gar nicht. Im Grunde sind sich alle über die üblicherweise notwendige
Normalisierung einig. Wir haben halt nur mal ein paar Sonderfälle aus der Schatulle gezogen.

Letzlich bleibt hier ehedem nichts anderes übrig als die Tabellen aufzuteilen und da
muß man sich halt die Tabelle mal genauer anschauen, wie man dies am günstigsten macht.

Grüße in die Runde // Martin


PS: Über Access sollte man nochmal nachdenken ob es da nicht eine Alternative gibt

[Cogito]

In diesem Zusammenhang hätte ich noch eine Frage:
Wie stellt man denn nun eigentlich die Syncronisation zwischen diesen ganzen ausgelagerten Tabellen sicher? Wenn jetzt zum Beispiel ein neuer Fonds angelegt wird und das PrimaryKey Feld eingegeben wurde, sollte man dann zum Speichern auffordern und in allen anderen Tabellen ebenfalls einen Datensatz mit dem gleichen PrimaryKey anlegen, bei Änderungen das gleiche? Falls ja, wie könnte man das in Delphi lösen, hat jemand ein kleines Beispiel oder einen Hinweis auf ein Event, in welchem man dies am besten macht?

[mkinzler]

Entweder sofort anlegen oder bei Bedarf. ich würde aber versuchen eine wirklich Normalisierung durchzuführen.

[quendolineDD]

Es gab doch zB in MySQL solche Sachen um Update und Insert/Delete-Anomalien zu vermeiden. Hatte ich auch mal in einem Projekt benutzt.
Google hilft: man nannte sie TRIGGER ;-)

Informationen können doch immer Ober- und Untergruppen zugeordnet werden. Versuche doch wie du schon angefangen hast, allgemeingültige Oberbegriffe zu finden um Inhalte deiner Tabelle auszulagern und somit die Anzahl der Spalten zu verkleinern. [Okay, das hat nun hier schon fast jeder gesagt]

[Cogito]

Zitat:

Zitat von quendolineDD

Es gab doch zB in MySQL solche Sachen um Update und Insert/Delete-Anomalien zu vermeiden. Hatte ich auch mal in einem Projekt benutzt.
Google hilft: man nannte sie TRIGGER ;-)

Informationen können doch immer Ober- und Untergruppen zugeordnet werden. Versuche doch wie du schon angefangen hast, allgemeingültige Oberbegriffe zu finden um Inhalte deiner Tabelle auszulagern und somit die Anzahl der Spalten zu verkleinern. [Okay, das hat nun hier schon fast jeder gesagt]

Trigger gibt es in Access leider nicht.

[DeddyH]

Das ist noch ein Grund, sich von Access zu verabschieden :zwinker: