[Betatest] CSV zu MySQL Konverter

Und was gewinnst du dadurch?

Ich kenne mich mit Patientensystemen auch nicht aus. Ist vielleicht kein gutes Beispiel.
Hier mal ein paar Limits für die Spaltenzahl gängiger DBS: MySQL 2599, PostgreSQL 1600, Oracle 1000, DB2 750. Das ist kein Schwanzvergleich, sondern wird wirklich auch benutzt. Ich habe schon OLAPS mit weit über 100 Spalten gesehen (nicht gezählt, nur drüber gescrollt).

Normalisierung sollte nur sinnvoll angewandt werden und nicht bei jedem Sch**ß und auch nicht unbedingt bis zur 5. Form runter brechen. Die Anzahl der Spalten einer Tabelle sagt auch nicht aus, ob die Datenbank sauber entworfen ist.

Original geschrieben von onemorenerd
Und was gewinnst du dadurch?

Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.

Original geschrieben von onemorenerd
Ich kenne mich mit Patientensystemen auch nicht aus. Ist vielleicht kein gutes Beispiel.
Hier mal ein paar Limits für die Spaltenzahl gängiger DBS: MySQL 2599, PostgreSQL 1600, Oracle 1000, DB2 750. Das ist kein Schwanzvergleich, sondern wird wirklich auch benutzt. Ich habe schon OLAPS mit weit über 100 Spalten gesehen (nicht gezählt, nur drüber gescrollt).

Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit.

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen viel besser umgehen als mit vielen Spalten.

http://www.intelligententerprise.com...leID=206800851

Original geschrieben von Benny-one
http://www.intelligententerprise.com...leID=206800851

Langfristige Archivierung ist halt ein Sonderfall. Aber gewöhnlich will man mit seinen Daten auch arbeiten und sie verändern.

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.

Das kannst du so pauschal nicht sagen. Deine Struktur da oben kackt ab, wenn ich zu einem Patienten alle Daten haben will. Du brauchst einen JOIN über 3 Tabellen (mindestens eine davon ist riesig!) und mußt über ein Resultset von 90 Datensätzen iterieren. Ohne deine sogenannte Normalisierung wäre es ein Datensatz, ein Griff, und bestenfalls ein Cache-Hit.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.

Normalisierung soll Redundanz und Inkonsistenz verhindern. Es soll nicht für Flexibilität sorgen. Das ist Sache der Anwendung.
Davon abgesehen ist es doch kein Problem, an 90 Spalten eine 91. anzuhängen.

Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit.

Das ist kein Vergleich, denn Wirtschaftlichkeit und Sicherheit haben mit Normalisierung nichts zu tun.

Ich halte es in dem Beispielfall mit den Patientendaten auch für sinnvoller mit einer "großen" Tabelle mit vielen Spalten zu arbeiten. Das ist genau so ein Fall wie mit OOP. Flexibilität ist zwar toll, aber einige Sachen auf viel zu viele Tabellen/Klassen zu abstrahieren ist oft zu viel des Guten und wird nur gemacht weil man denkt es sei dann automatisch besser.

@nerd, doch schon mit Wirtschaftlichkeit ... denn wenn du mit Normalisierung übertreibst, explodieren deine Abfrage-String und auch die entsprechenden Matrixenoperationen, somit leidet die Anwendung an Performanceverlust ... dein Programm arbeitet somit unwirtschaftlich

Original geschrieben von asp2php
@nerd, doch schon mit Wirtschaftlichkeit ... denn wenn du mit Normalisierung übertreibst, explodieren deine Abfrage-String und auch die entsprechenden Matrixenoperationen, somit leidet die Anwendung an Performanceverlust ... dein Programm arbeitet somit unwirtschaftlich

Wenn du bei jeder kleinen Änderungen einen Programmierer brauchst, der Code und Datenbankstruktur anpassen muss, ist das auch nicht wirklich wirtschaftlich.

Original geschrieben von h3ll
Wenn du bei jeder kleinen Änderungen einen Programmierer brauchst, der Code und Datenbankstruktur anpassen muss, ist das auch nicht wirklich wirtschaftlich.

Als ob man ein Programm täglich ändert ... die Abfragen aber werden aber schon täglich abgesetzt ... kleine Rechnung:

1000 MA à 50 EUR/Std. ... sagen wir mal max. 1 Stunde/Monat für das Warten auf die Abfragergebnisse => 50000 EUR ... und das gegen eine Änderung mit einem Tagessatz/Mann(Frau) von ca. 2000 EUR ... nun, was ist teurer?

Original geschrieben von asp2php
Als ob man ein Programm täglich ändert

Du kennst anscheinend unsere Kunden nicht

Original geschrieben von TroX
Ähm... Datenbanknormalisierung?

Was hat die Anzahl der atomaren Attribute mit der Normalisierung zu tun?

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.



Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit.

Also das höre ich zum ersten Mal.... warum ist den ein unnötiger Join schneller ein ein einfaches Select über viele Spalten?

Original geschrieben von asp2php
1000 MA à 50 EUR/Std. ... sagen wir mal max. 1 Stunde/Monat für das Warten auf die Abfragergebnisse => 50000 EUR

Dieser Rechnung liegt die Annahme zugrunde, dass der Join von patient und patient_wert schneller läuft als ein einfaches Select. Hinzu kommt, dass bei der Join-Variante ein Resultset mit 90 Datensätzen entsteht, dass man in einer Schleife abholen und in ein Array flachklopfen muß.
Gewagte Annahme.

Ich habs so verstanden, das asp2php schon für mehrere Spalten ist, also genau das gleiche Argument wie deins.