max. Anzahl Felder erreicht - was nun?

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