Wie viele Spalten zu viele Spalten? [geschlossen]

Question

Ich habe bemerkt, dass eine Menge Leute hier zitiert Tabellen mit 20+ in einer Tabellenspalt (ich habe so viel wie 55 zu sehen ist). Jetzt gebe ich nicht vor einem Datenbank-Design-Experten zu sein, aber ich habe immer gehört, dass dies eine schreckliche Praxis. Als ich das sehen, schlage ich in der Regel Aufspaltung in zwei Tabellen mit einer Eins-zu Eins-Beziehung: eine mit den am häufigsten verwendeten Daten enthält, die andere mit den am wenigsten häufig verwendeten Daten. Obwohl zur gleichen Zeit, es ist die mögliche Ausgabe von Leistung (weniger JOINs und so weiter). Also meine Frage ist:

Wenn es um die wirklich großen Maßstab Datenbanken kommt, gibt es tatsächlich einen Vorteil, eine große Menge von Spalten, trotz der Tatsache, dass diese in der Regel führt zu viele NULL-Werte?

Welche eher eine Performance Hit ist: viele Spalten mit vielen NULLs oder weniger Spalten mit vielen JOIN

Answer 1

Das Design der Tabelle hängt von der Einheit muss speichern. Wenn alle Daten zusammengehört, dann 50 Spalten (oder sogar 100) könnten die richtige Sache zu tun.

Solange die Tabelle normalisiert , gibt es keine Faustregel gilt: Größe in Bezug auf, auseinander von Datenbank-Funktionen und die Notwendigkeit, zu optimieren.

Answer 2

Ich bin mit Oded. Ich habe Tabellen in ihnen mit 500 Spalten zu sehen, und alle Spalten in ihnen an der richtigen Stelle waren. Man denke nur an die Zahl der Tatsachen man sich wünschen könnte etwa ein alltägliches Objekt zu speichern, und Sie werden bald sehen, warum.

Wenn es ungünstig erweist sich alle diese Spalten auswählen oder festlegen, welche Spalten wählen, wenn Sie nur in einem geringen Anteil an ihnen interessiert sind, können Sie es sich lohnt, finden eine Ansicht zu definieren.

Answer 3

Wie viele Spalten zu viele Spalten?

Wenn Sie das Gefühl, es macht keinen Sinn mehr oder ist direkt eine weitere Spalte hinzuzufügen.

hängt in der Regel auf Anfrage.

Answer 4

odbc hat eine Zeichenbegrenzung von 8000 .... so dass eine physikalische Grenze, jenseits derer die Dinge sehr frustrierend.

Ich arbeitete an einem Tisch, die 138 Spalten hatten .. es schrecklich geschrieben wurde und normalisiert worden sein könnte. Obwohl diese Datenbank scheint von der Schaffung von jemandem schon gewundert, warum gibt es Konventionen in Datenbank-Design und zu entscheiden, sie alle auf einmal zu testen.

Mit sehr großen Tabellen abgeflacht ist ziemlich üblich, wenn Sie in Daten erhalten Warehousing und Reporting-Server. Sie sind nur viel schneller und bedeutet, dass Sie nicht Ihre Datenbank entirley für die Leistung im RAM speichern müssen.

Answer 5

Nach meiner Erfahrung ist es besser, weniger zu haben, schließt sich als diejenigen, neigen dazu, in großer Datenbank zu oft besonders geschehen. Solange Ihre Datenbanktabellen Einheit speichern sollen (Schüler, Lehrer usw.) sollte in Ordnung sein. So, dass dies als ein Objekt in Ihr Code später dargestellt werden. Also, wenn Sie das Objekt in mehrere Tabellen aufgeteilt werden Sie später mehr Verknüpfungen zu füllen, um Ihr Objekt zu verwenden. wenn Sie ORM auch verwenden, um Ihre Datenzugriffsschicht (wie Linq in .Net) zu erzeugen ist, wird für jede Tabelle separate Klassen erzeugen (natürlich mit einer Beziehung zwischen ihnen, aber immer noch), und dies wird schwieriger zu bedienen.

Eine andere Sache ist, dass Sie, welche Spalten zurück in Ihrer Abfrage angeben können, und dies wird die Daten zu reduzieren, die für Ihre Anwendung übergeben wird, aber wenn Sie auch nur eine einzige Spalte aus einer anderen Tabelle benötigt, was Sie tun müssen, um die Verbindung. Und in den meisten Fällen, wie Sie so viele Spalten haben, dann ist die Wahrscheinlichkeit große Menge an Daten in der DB gespeichert zu haben, sind hoch. Also diese kommen würde mehr schaden, als die NULL-Werte.

Jedes Projekt, das ich gearbeitet habe ist anders, so dass Sie die Balance für jede Geschichte finden sollte.

Answer 6

Zu viele Spalten Ergebnisse in vielen Nullen (böse) und einem sperrigen Objekt der Tabelle abgebildet wird. Dies schadet der Lesbarkeit in der IDE und behindert Wartung (steigende Entwicklungskosten). Wenn Sie schnell brauchen in einigen Fällen liest verwenden denormalisierter Tabellen z.B. ausschließlich für die Berichterstattung oder Abfragen (Suche nach dem „CQRS“ -Muster) verwendet. Ja „Person“ hat eine Million Attribute, aber Sie können diese monothilic Tabellen (Design vorausgeht Normalisierung) brechen auf die kleineren Einheiten entsprechen ( „Adresse“, „Telefon“, „Hobby“) statt neue Spalten für jeden neuen Anwendungsfall hinzuzufügen. Mit kleineren Objekten (und Tabellen) bringt so viele Vorteile; sie ermöglichen Dinge wie Unit-Tests, OOP und SOLID Praktiken.

Auch, wie es zu bündeln zahlreiche Spalten zu vermeiden, in Bezug auf schließt sich, denke ich, der Performance-Gewinn aus der Vermeidung schließt sich durch Indexpflege verloren, eine typische Arbeitsbelastung der Lese- und Schreibvorgänge übernehmen. Hinzufügen von Indizes für Felder aus Gründen der Leseleistung könnte sein, das eine Notwendigkeit, diese Felder in die eigene Tabelle zu bewegen.

Answer 7

Which is more of a performance hit: lots of columns with lots of NULLs, or fewer columns with lots of JOINs?

It is purely depends on data you store, indexes you make and so on. No one can ensure you that one works better than another without knowing what are you storing. Generally normalization rules will "force" you separate data to different tables and user FKeys if you have large table but i disagree that it ALWAYS performs better than one big table. You can end with 6-7 level joins in dozens of queries that sometimes will cause errors because there much more chances to create an error in larger queries that in simple ones.

If you post some requirements of what you are doing maybe we can help you with designing the DB properly.

Answer 8

It also highly depends on the usecase for your table. If you want to optimize it for reading then it might be a good idea to keep it all together in one table.

In the NO-SQL world (cassandra/hbase for example) there are no constraints on the number of columns and it's actually considered a good practice to have many columns. This also comes from the way it is stored (no gaps). Worth while investigating.

Answer 9

What business need requires more than 60 columns in any data set, let alone a TSQL Table? If there is such a business need, then a Pivot is in order, and the columns should be rows. For example, in the Mining industry, there may be 600 different measurements taken in an assay. The name of each measurement could be a column name. But why create a table with 600 columns and rows of measurements? A geologist would measure the mine each day, perhaps, and fill in the log of 600 columns on one row. That sounds to me like the geologist will lose his mind, and he won't find a sheet of paper long enough. Perhaps a roll would work, but then he would have to unroll the roll and roll it back up again.

Answer 10

It's better to use a single table by where you can avoid using joins while querying it depends on whether the columns are of same entity or different entity.

For example, assume you are doing a database design for work flow where some fields will be edited by junior workers, and some fields by senior workers. In this case it is better to have all the columns in a single table.