Ankündigung

Einklappen
Keine Ankündigung bisher.

Bestell-Tabelle ok?

Einklappen

Neue Werbung 2019

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

  • Bestell-Tabelle ok?

    Hi ich hab hier ne Tabelle aus einem shopsytem. Ich frag mich ob die tabelle nicht sehr *scheisse* ist, weil sehr viele felder bei der bestellung leer gelassen werden können. Ausserdem les ich überall was von Redundanz und den 3 Normalformen einer DB und wenn ich mir dann die Tabellen von bekannten Shopsystemen angucke ist da nix von 3-Normalformen-Muster-Tabellen, sondern genau das Gegenteil. Also diese Tabelle is doch voll redundant oder irre ich mich da? Man könnte lieferadresse, rechnungsadresse etc auslagern oder net. Wär das sinnvoll, besser? Ich bin nur grad voll verwirr. Ich plane ein Datenbankmodell zu machen, les mich durch Tutorials wie man sowas am besten macht und in der Praxis dann , wenn man sich ein Live-Bespiel ansehen möchte kommen da sone Tabellen bei raus....
    CREATE TABLE customer_order (
    id int(10) NOT NULL auto_increment,
    adress_id int(10) NOT NULL default '0',
    order_id varchar(22) NOT NULL default '',
    currency_iso char(3) NOT NULL default '',
    currency_key char(3) NOT NULL default '',
    currency_rate decimal(15,4) NOT NULL default '0.0000',
    bank_name varchar(100) NOT NULL default '',
    bank_owner varchar(150) NOT NULL default '',
    bank_account varchar(20) NOT NULL default '',
    bank_number varchar(20) NOT NULL default '',
    cc_owner varchar(100) NOT NULL default '',
    cc_institute varchar(20) NOT NULL default '',
    cc_number varchar(30) NOT NULL default '',
    cc_valid varchar(4) NOT NULL default '',
    cc_check varchar(5) NOT NULL default '',
    cc_phone varchar(30) NOT NULL default '',
    cc_street varchar(100) NOT NULL default '',
    cc_zip varchar(10) NOT NULL default '',
    cc_city varchar(60) NOT NULL default '',
    cc_mail varchar(60) NOT NULL default '',
    payment_method char(3) NOT NULL default '',
    payment_costs decimal(12,2) NOT NULL default '0.00',
    payment_tax decimal(12,2) NOT NULL default '0.00',
    shipping_costs decimal(12,2) NOT NULL default '0.00',
    shipping_tax decimal(12,2) NOT NULL default '0.00',
    desire_date date NOT NULL default '0000-00-00',
    voucher_number varchar(15) NOT NULL default '',
    voucher_percent decimal(5,2) NOT NULL default '0.00',
    voucher_amount decimal(12,2) NOT NULL default '0.00',
    voucher_expirationdate date NOT NULL default '0000-00-00',
    memo text NOT NULL,
    feedback text NOT NULL,
    rating tinyint(1) NOT NULL default '0',
    order_status enum('N','W','C','D','R','P','IN') NOT NULL default 'N',
    finished enum('Y','N') NOT NULL default 'N',
    incomplete enum('Y','N') NOT NULL default 'Y',
    modus varchar(5) NOT NULL default '',
    order_date date NOT NULL default '0000-00-00',
    order_time time NOT NULL default '00:00:00',
    discount_type char(1) NOT NULL default '',
    discount decimal(12,2) NOT NULL default '0.00',
    discount_per char(1) NOT NULL default '',
    discount_finished decimal(12,2) NOT NULL default '0.00',
    notification text NOT NULL,
    free_1 varchar(100) NOT NULL default '',
    free_2 varchar(100) NOT NULL default '',
    free_3 varchar(100) NOT NULL default '',
    free_4 varchar(100) NOT NULL default '',
    free_5 varchar(100) NOT NULL default '',
    free_6 varchar(100) NOT NULL default '',
    sid varchar(50) NOT NULL default '',
    ip varchar(20) NOT NULL default '',
    pdf_bill varchar(19) NOT NULL default '',
    KEY id (id,adress_id,order_id),
    KEY incomplete (incomplete)
    )


  • #2
    Erklär doch mal genauer, was die einzelnen Elemente überhaupt sind. Sonst kann man dir schlecht helfen. Zumindest kannst du mal die Blöcke abgrenzen und kurz beschreiben.

    Kommentar


    • #3
      Ich hab hier ein besseres Beispiel:

      Code:
      CREATE TABLE orders (
        orders_id int NOT NULL auto_increment,
        customers_id int NOT NULL,
        customers_name varchar(64) NOT NULL,
        customers_company varchar(32),
        customers_street_address varchar(64) NOT NULL,
        customers_suburb varchar(32),
        customers_city varchar(32) NOT NULL,
        customers_postcode varchar(10) NOT NULL,
        customers_state varchar(32),
        customers_country varchar(32) NOT NULL,
        customers_telephone varchar(32) NOT NULL,
        customers_email_address varchar(96) NOT NULL,
        customers_address_format_id int(5) NOT NULL,
        delivery_name varchar(64) NOT NULL,
        delivery_company varchar(32),
        delivery_street_address varchar(64) NOT NULL,
        delivery_suburb varchar(32),
        delivery_city varchar(32) NOT NULL,
        delivery_postcode varchar(10) NOT NULL,
        delivery_state varchar(32),
        delivery_country varchar(32) NOT NULL,
        delivery_address_format_id int(5) NOT NULL,
        billing_name varchar(64) NOT NULL,
        billing_company varchar(32),
        billing_street_address varchar(64) NOT NULL,
        billing_suburb varchar(32),
        billing_city varchar(32) NOT NULL,
        billing_postcode varchar(10) NOT NULL,
        billing_state varchar(32),
        billing_country varchar(32) NOT NULL,
        billing_address_format_id int(5) NOT NULL,
        payment_method varchar(32) NOT NULL,
        cc_type varchar(20),
        cc_owner varchar(64),
        cc_number varchar(32),
        cc_expires varchar(4),
        last_modified datetime,
        date_purchased datetime,
        orders_status int(5) NOT NULL,
        orders_date_finished datetime,
        currency char(3),
        currency_value decimal(14,6),
        PRIMARY KEY (orders_id)
      );
      Diese Tabelle stammt vom Shopsystem osc. Wenn ein Kunde was bestellt, werden in dieser einen einzigen einen Tabelle Liefer- und Rechnungsadresse und Kundenadresse, Zahlungsart, Zahlungsinfos wie Kreditkartendaten usw. gespeichert und das jedesmal wenn ein Kunde, der dem System schon bekannt ist, weil er schonmal bestellt hat. Ich frage mich jetzt ob das wirklich sinnvoll ist, wegen redundanz und so.. Ich würde zb die Rechnungsadresse in einer Tabelle auslagern, die Liferadresse, die Zahlungsdaten damit die nicht bei jeder Bestellung neu eingetragen werden müssen. Das osc das jetzt aber alles in eine Tabelle packt, verwirrt mich jetzt... osc kann aber doch irgendwie nicht falsch liegen, weil das ein bewährtes shopsystem ist. Was hab ich falsch verstanden?

      Kommentar


      • #4
        Ich vermute mal das wird deshalb explizit in die Bestell-Tabelle reingeschrieben, damit nicht folgender Fehler auftreten kann:

        Kunde K1 meldet sich an, schreibt seine Lieferadresse und Rechnungsadresse in die Felder.
        Nun bestellt Kunde K1 etwas: Bestellung B1 wartet auf Abfertigung.
        Kunde K1 ändert seine Adresse.
        Kunde K1 bestellt erneut etwas. Bestellung B2 wartet auf Abfertigung.
        Bestellung B1 kann versendet werden. Nun könnte durch die Normalisierung der Fall eintreten, dass Bestellung B1 an die geänderte Adresse geschickt wird. Dies hat der Kunde aber nicht gewollt. Schließlich muss er sich bewußt sein, dass eine Änderung nicht rückwirkend "wirkt".

        Insofern würde die Tabellenstruktur Sinn machen. Ich würde trotzdem die Adressen auslagern und eben obigen Fall im Auge behalten.

        Kommentar


        • #5
          Ich kann mich dem nur anschließen. Eine Bestellung ist einer unveränderlichen Rechnungs- und Lieferanschrift zugeordnet (mal vom Kundenanruf "schickt es mir doch lieber ins Büro, nicht nach Hause" abgesehen). Das ist die Willenserklärung, die der Kunde abgibt, nicht etwa "schick mir
          das Zeug an die Adresses, die ich zum Zeitpunkt eures Warenausgangs/Rechnungsstelung im
          System eingetragen hab". Aber, um Redundanzen zu vermeiden, musst du natürlich alle Adressen
          in eine eigene Tabelle packen und darauf dann von den einzelnen Bestellungen (je für Liefer- und
          Rechnungsanschrift) darauf referenzieren. Die Benutzer kanns du dann auch vielfältig mit
          Adressen verknüpfen (Standard-Rechnungsanschrift, Lieferanschrift 1, Liferanschrift 2 etc.).

          Wichtig ist dann eben, dass du diese Adress-Sätze nicht überschreibst, sondern kopierst, wenn
          der Benutzer seine Adressdaten ändert, aber das ist ja klar.

          Basti

          Kommentar

          Lädt...
          X