Ankündigung

Einklappen
Keine Ankündigung bisher.

Relationale Datenbank umdesignen, wie?

Einklappen

Neue Werbung 2019

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

  • Relationale Datenbank umdesignen, wie?

    hi, ich stehe momentan vor einem problem, das eigentlich nicht selten vorkommt, ich muss eine datenbank umstrukturieren. Über die zeit haben sich viele neue spalten zu der einst sehr durchdachten struktur dazugesellt, und jetzt scheint mir einfach eine neustrukturierung angebracht. Hier und da müssen ein paar spalten aus einer tabelle in eine neue tabelle verschoben werden, woanders müssen wieder spalten von einer tabelle in eine andere wandern usw, was halt so anfallen kann. ich hab mir anfangs gedacht, ein phpscript zu schreiben, das die daten mit einer riesigen abfrage erstmal alle einließt, und jede eingelesene zeile dann quasi neu ordnet. das ist 1. sehr aufwendig, weil man teilweise sehr viele abfragen einbauen müsste, und 2. ists auch noch langsam. falls das script dann mal abbricht, kann man von vorn beginnen, also nicht sehr toll so ein verfahren. da ich darin noch keine erfahrung habe, weiß ich nicht, obs bessere wege und mittel gibt, wesshalb ich gerne hier mal ein tipps sammeln würde, wie man sowas geschickt anstellt, ich wäre euch sehr dankbar dafür. hilfreiche tools, usw, kann alles genannt werden. google scheint da nicht sehr viel gefunden zu haben, zu diesem thema, oder ich hab einfach nach den falschen stichworten gesucht... danke


  • #2
    Hi,

    wieso bist du der Meinung deine Datenbank muss umdesignt werden? Für mich wäre der einzig sinnvolle Grund das beim erweitern der Daten nicht auf Normalisierung geachtet wurde. Wenn dem so ist, dann findest du unmengen an Information über Normalisierung einer Datenbank im Netz. Da geht es vorallem um nachträgliches normalisieren und das wäre ja in diesem Fall genau das.

    Oder geht es dir mehr um die technische Umsetzung einer Normalisierung? Also das kann, je nach Datenbank, wirklich übel werden. Was mir persönlich beim umstrukturieren auf jeden Fall immer geholfen hat war der INSERT - SELECT. Das hat nämlich den großen Vorteil das man nirgends etwas zwischen speichern muss um es von einer Tabelle in eine andere zu bekommen. Ein Beispiel:

    INSERT INTO neue_tabelle (ref_id,data) SELECT id,data FROM alte_tabelle

    Das kann man einfach so an einen MySQL Server schicken und die Daten werden kopiert ohne großen Aufwand.

    Ich hoffe ich konnte dir weiterhelfen.

    Kommentar


    • #3
      Zitat von cycap Beitrag anzeigen
      Hi,

      wieso bist du der Meinung deine Datenbank muss umdesignt werden? Für mich wäre der einzig sinnvolle Grund das beim erweitern der Daten nicht auf Normalisierung geachtet wurde.
      so ist es leider
      Zitat von cycap Beitrag anzeigen
      Wenn dem so ist, dann findest du unmengen an Information über Normalisierung einer Datenbank im Netz. Da geht es vorallem um nachträgliches normalisieren und das wäre ja in diesem Fall genau das.
      ja, das normalisieren in der theorie ist nicht das problem, sondern eben das nachträgliche normalisieren in der datenbank...
      Zitat von cycap Beitrag anzeigen
      Oder geht es dir mehr um die technische Umsetzung einer Normalisierung? Also das kann, je nach Datenbank, wirklich übel werden.
      genau das habich befürchtet
      Zitat von cycap Beitrag anzeigen
      Was mir persönlich beim umstrukturieren auf jeden Fall immer geholfen hat war der INSERT - SELECT. Das hat nämlich den großen Vorteil das man nirgends etwas zwischen speichern muss um es von einer Tabelle in eine andere zu bekommen. Ein Beispiel:

      INSERT INTO neue_tabelle (ref_id,data) SELECT id,data FROM alte_tabelle

      Das kann man einfach so an einen MySQL Server schicken und die Daten werden kopiert ohne großen Aufwand.

      Ich hoffe ich konnte dir weiterhelfen.
      okay, das wusste ich noch garnich, das sowas möglich ist es geht bei mir um folgedes, mal ein beispiel: in einer artikeltabelle sind unmengen von artikeln drin, einer dieser attribute nennt sich "kommentar", wo sich die admins notizen hinterlegen konnten. am anfang des projekts war das auch ausreichend, doch jetzt soll man mehrere kommentare an ein artikel hängen können, also muss ich die kommentare aus der artikel-tabelle rausnehmen, eine eigene tabelle dafür erstellen, wo ich dann die artikel-id als referenz angebe. jetz bräuchte ich ein sql-statement, das mir die artikeltbl nach kommentaren durchsucht, falls es ein kommentar gibt, also kommentar "", dann soll eben dieser kommentar in die neue tabelle, mit der artikel-id als referenz. das is nur ein beispiel, gibt leider viel komplexere probleme. hat da jemand eine idee?

      Kommentar


      • #4
        Für das Beispiel ist mein Beispiel genau passend! Du legst eine neue Tabelle an mit autoid, id_artikel und kommentar und dann gehts los

        INSERT INTO neue_tabelle (id_artikel,kommentar) SELECT id,kommentar FROM alte_tabelle WHERE kommentar NOT LIKE ''

        Und fertig!

        Es gibt natürlich Fälle wo das so nicht klappt. Zum Beispiel wenn mehrere Werte in einem Feld stehen, zum Beispiel durch Komma getrennt. Da musst du dann schon sehr mit SQL tricksen oder einfach z.B. ein PHP Script zur Hilfe nehmen.

        Kommentar


        • #5
          hm is ja einfacher als ich dachte... danke!

          hab aber noch ein szenario, das man wohl net so einfach gelöst bekommt. angenommen jeder artikel bekommt max 1 kommentar, aber dafür kann ein kommentar zu mehreren artikeln gehören, dann würde der fremdschlüssel nicht mehr in der kommentare-tabelle sein, sondern in der artikel-tabelle.

          dann müsste ich im ersten schritt die kommentare auslagern, und wie gehts dann weiter? wie bekomme ich nun die richtigen ids der kommentare wieder in die artikel-tabelle?

          etwa so in der art:
          update artikel SET artikel.kommentar_id = kommentare.id where artikel.kommentar = kommentare.kommentar;

          wäre das die lösung oder kriegt man das in einem schlag hin?
          danke schonmal

          Kommentar


          • #6
            Da wirst du glaub ich nicht um ein Script herum kommen.

            Kommentar

            Lädt...
            X