[Betatest] CSV zu MySQL Konverter

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    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).

    Kommentar


    • #17
      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.

      Kommentar


      • #18
        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.
        Zuletzt geändert von h3ll; 11.11.2008, 14:22.

        Kommentar


        • #19
          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
          Sunshine CMS
          BannerAdManagement
          Borlabs - because we make IT easier
          Formulargenerator [color=red]Neu![/color]
          Herkunftsstatistik [color=red]Neu![/color]

          Kommentar


          • #20
            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.

            Kommentar


            • #21
              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.

              Kommentar


              • #22
                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.

                Kommentar


                • #23
                  @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

                  Kommentar


                  • #24
                    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.

                    Kommentar


                    • #25
                      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?
                      Zuletzt geändert von asp2php; 11.11.2008, 16:01.

                      Kommentar


                      • #26
                        Original geschrieben von asp2php
                        Als ob man ein Programm täglich ändert
                        Du kennst anscheinend unsere Kunden nicht

                        Kommentar


                        • #27
                          Original geschrieben von TroX
                          Ähm... Datenbanknormalisierung?
                          Was hat die Anzahl der atomaren Attribute mit der Normalisierung zu tun?
                          Download ET-Chat v3.x.x

                          Kommentar


                          • #28
                            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?
                            Download ET-Chat v3.x.x

                            Kommentar


                            • #29
                              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.

                              Kommentar


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

                                Kommentar

                                Lädt...
                                X