Sie sind aktuell nicht angemeldet.

Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 01.05.15 16:39
Nehmen wir an wir wollen eine bestehende Software nach VB.net migrieren... Der Artikeldatensatz hat aktuell ca. 400 einzelne Felder. Das sind z.B. für eine Access Datenbank zu viele Felder um den Artikelsatz in einer Datenbank abzubilden. Nun könnte man natürlich mehrere Tabellen mit demselben Primärkey definieren, die alle nur Teilbereiche des Artikelstammsatzes abbilden, also z.B. alle Maße in eine Tabelle, alle Bezeichnungen in eine andere Tabelle etc... Aber ist das wirklich der richtige Weg? Natürlich käme auch eine SQL-Datenbank in Frage. Aber die Problematik dort ist ja ähnlich. Beispielsweise darf eine INSERT-Anweisung ja auch nicht unendlich lang werden... Wie geht man hier am sinnvollsten vor? Natürlich gibt es diverse Bücher zum Thema Datenbankzugriff aus VB.net oder Datenbankentwicklung allgemein, aber zu dieser Fragestellung habe ich nichts gefunden. Kennt jemand ein gutes, am Besten kostenloses Ebook zu dem Thema Datenbankzugriff, Daten-Validierung etc. oder kurz Anwendungsentwicklung an Hand eines praktischen Übungsfalls?

Re: Was tun bei umfangreichen Tabellen?
Autor: powerzone3000
Datum: 01.05.15 18:14
Hallo, das Stichwort nach dem du suchen solltest ist "Normalisierung". Ich habe leider nicht direkt eine Buchempfehlung, aber diesen Artikel habe ich mal kurz überflogen und hat einen ganz guten Eindruck auf mich gemacht.

Re: Was tun bei umfangreichen Tabellen?
Autor: Manfred X
Datum: 01.05.15 19:58
Hallo! Die Limits in MS-SQL-Server sollten für deine Stammdaten-Tabelle kein Problem sein.

Re: Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 01.05.15 20:03
Dieser "Punkt" ist bereits berücksichtigt. Selbstverständlich sind nur die wirklich relevanten Felder noch im Artikelsatz selber. "Unterdaten" wie Warengruppenbezeichnung, Qualität, Herkunftsland sind bereits in andere Datensätze bzw. Tabellen ausgelagert. Trotzdem danke für den Link und Deine Hilfe.

Re: Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 01.05.15 20:09
In der Tat. 4096 Felder in einem INSERT Statement sollten weit mehr als ausreichen. Hier hatte ich mit deutlich weniger gerechnet. Gilt das auch für die SQL-Server Express Version? Irgendwo meine ich mal von einer "integrierten" SQL-Datenbank von MS gelesen zu haben, die z.B. vom Media Player genutzt wird. Ich weiß nur den Namen nicht mehr SQL Light? Vielen Dank für die Infos und die Hilfe.

Re: Was tun bei umfangreichen Tabellen?
Autor: Manfred X
Datum: 01.05.15 20:19
Zu diesen Fragen könnten folgende Links relevant sein: http://blogs.msdn.com/b/jerrynixon/archive/2012/02/26/sql-express-v-localdb-v-sql-compact-edition.aspx https://msdn.microsoft.com/en-us/library/ms172451%28v=SQL.110%29.aspx

Re: Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 01.05.15 20:48
Compact.... genau das meinte ich. Danke für die Links. Da habe ich jetzt was zu lesen

Re: Was tun bei umfangreichen Tabellen?
Autor: Manfred X
Datum: 01.05.15 21:06
Bei Nutzung der eingebetteten Compact-Datenbank sind die Restriktionen zu beachten (Größe der Dateien, Datensätze). Ich empfehle, auch SQL-Compact-Datenbanken über das MS-SQL-Server Management-Studio einzurichten.

Re: Was tun bei umfangreichen Tabellen?
Autor: effeff
Datum: 02.05.15 00:12
400 Felder für einen Datensatz glaube ich Dir nicht... Die von ManfredX angesprochene Normalisierung hat - glaube ich - nicht so richtig statt gefunden... Natürlich gehören alle Maße in eine Tabelle, alle Bezeichnungen in eine andere, alle Farben in die dritte, etc. Überlege mal: Jeder Artikel hat eine bestimmte Größe. Jeder Artikel hat eine bestimmte Bezeichnung. Jeder Artikel hat eine bestimmte Farbe. Vielleicht auch noch eine bestimmte Verpackung. Aber das gehört in einzelne Tabellen und garantiert nicht in eine einzelne Tabelle... Such mal im Internet nach "Relationale Datenbank" und "Normalisierung"... EALA FREYA FRESENA

Re: Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 02.05.15 09:50
Ich weiß dass es viel klingt, aber es ist nun einmal so. Viele der Felder sind Kennzeichen wie "Glutenfrei" oder Nährwertangaben aber eben auch die Artikelbezeichnung, der Preis, Staffelpreise... Natürlich könnte man die Preise jetzt wieder in eine eigene Tabelle auslagern, die als Key ebenfalls die Artikelnummer hat... Letztlich könnte man dann aber jedes der 400 Felder in eine eigene Tabelle legen. Aber wo bleibt da die Übersichtlichkeit und die Performance wenn ich statt einem Datensatz 400 lesen muss? Wir haben das damals so gelernt und bis heute so gehalten, dass wiederkehrende Informationen ausgelagert werden. Also z.B. nicht in jedem Datensatz "blau" als Farbe steht, sondern nur eine Kennziffer, die auf die Farbe verweist. Daten, die direkt zum Artikel gehören, wie der Preis aber am Artikel selbst bleiben. Ich möchte Deinen Hinweis damit nicht abbügeln oder verwerfen. Vielmehr ist das berücksichtigt. Man könnte jetzt nur diskutieren wie weit man "zerstückeln" sollte oder nicht - und ich denke dass da jeder für sich zu einem anderen Ergebnis kommen wird.

Re: Was tun bei umfangreichen Tabellen?
Autor: Schudi
Datum: 02.05.15 09:51
Vielen Dank für den Hinweis. Werde ich tun.

Re: Was tun bei umfangreichen Tabellen?
Autor: DotNetErbse
Datum: 17.03.16 10:57
Staffelpreise gehören in jedem Fall in eine eigene Tabelle, schon weil sie terminiert sein können. Poste doch mal die 400 Feldbezeichnungen... Mit freundlichen Gr??en DotNetErbse [Es hei?t Paket und nicht Packet, auch wenn Standard augenscheinlich von Standar(t)e kommt,hei?t es dennoch Standar(d)]

Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden. Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  Gesamtübersicht

Suchen