Änderungen an Tabellen durch Admin - muss das sein?

[webald]

Bin ich der einzige, den es stört, dass bei manchen Änderungen im Shop Tabellen angelegt bzw. Spalten hinzugefügt und gelöscht werden?

Ich nehme da mal als typisches Beispiel die Kundengruppen:
Neue Kundengruppe => neue Tabelle personal_offer_by_customers_status_X und neue Spalte group_permission_X in Tabelle products.

Beim Löschen passiert genau der umgekehrte Weg und es werden Spalten und Taballen gelöscht.

Da baut man dann eine Abfrage und muss davon ausgehen, dass durch den normalen Shopbetrieb plötzlich Spalten in der abgefragten Tabelle fehlen => Sql-Error, Spalte gibt es nicht.

Stört das sonst keinen?

Linkback: https://www.modified-shop.org/forum/index.php?topic=32135.0

[Bonsai]

Nein, stört nicht. Man kann die Abfragen ja so bauen, dass zuerst geprüft wird wie viele Kundengruppen da sind.

[webald]

Dann mach mir mal ein Beispiel, wie Du die Tabelle products abfragst und das Resultset an eine Funktion weitergibst, die den Inhalt des resultsets verarbeiten soll. Ganz lustig wird es dann wenn Du das nicht in PHP machen sollst, sondern in einer anderen Sprache etwa C# oder VB.

Die Anzahl sagt übrigens nichts über die Benennung der Spalten/bzw. Tabelle aus. Löscht man etwa die Kundengruppe "Händler" (=3) dann fehlt group_permission_3 zwar, aber group_permission_4 ist noch da. Die Anzahl beträgt aber jetzt nun noch 3 und nicht 4.

[Bonsai]

Code: SQL  [Auswählen]

DESCRIBE products

über eine Schleife laufen zu lassen die nach group_permission_ sucht?

Hab so was ähnliches für eine Sybase Datenbank gemacht. Da wird der Typ des Feldes abgefragt. Schöne Überraschung heute war, seit dem Update der DB ist "int" plötzlich "integer" und somit warf mein Programm "Fehler: Undefinierter Feldtyp" aus
Wenigstens ist die Fehlermeldung jetzt besser. Im Zuge des Debuggens wurde die Fehlermeldung zu:
"Fehler: Undefinierter Feldtyp für Spalte $x in Tabelle $y"

[webald]

Zu prüfen ob es die Spalte gibt oder nicht ist unproblematisch, da gibt es genug Möglichkeiten.

Das Problem ist, mit dem Ergebnis weiterzuarbeiten.

Mit einer Abfrage

Code: SQL  [Auswählen]

SELECT col1, col2, col3, col4, col5 FROM myTable

ist die Ergebnisstruktur definiert und kann problemlos in einer anderen Funktion weiterverarbeitet werden.

Eine Abfrage

Code: SQL  [Auswählen]

SELECT * FROM myTable

kann das gleiche Ergebnis liefern, muss aber nicht. Erst recht nicht, wenn Spalten gelöscht oder hinzugefügt werden. Sie geht immer, liefert aber ein undefiniertes Ergbnis.

Eine Funktion, die aber ein Array aus col1, col2, col3, col4, col5 erwartet funktioniert bei einem Array aus col1, col2, col4, col5 aber nicht mehr oder nicht mehr fehlerfrei.

Ich kann jetzt natürlich hergehen und solche "gefährlichen" Spalten und Tabellen aus den Abfragen raus zu lassen. Stattdessen frage ich die dann halt in einzelnen Schritten sprich Queries ab, was aber zu einer unnötigen Erhöhung der Anzahl der Abfragen und wohl auch zu unnötig übertragener Datenmenge führen würde. Das will ich ja eigentlich nicht.

[Bonsai]

Eine Funktion, die aber ein Array aus col1, col2, col3, col4, col5 erwartet funktioniert bei einem Array aus col1, col2, col4, col5 aber nicht mehr oder nicht mehr fehlerfrei.

Die Funktion kann aber vor Weiterverarbeitung prüfen welche problematischen Spalten vorhanden sind.

Code: PHP  [Auswählen]

if (array_key_exists('col1',$data)) {
  // was auch immer
}

[webald]

Das mag in PHP funktionieren, weil das mit den Datentypen quasi egal ist (auch wenn man es der Sicherheit wegen nutzen sollte); in anderen Sprachen geht das so einfach nicht. Um bei der Ausgangstabelle zu bleiben:

Diese würde ich in .NET als Array der Klasse Product darstellen, und die Spalten wären die Eigenschaften.
Das ist ein Produkt (abgekürzt):

Code: PHP  [Auswählen]

Public Class product

    Public Property products_id
    Public Property products_ean
    Public Property products_quantity
    Public Property products_ebay_quantity
    Public Property products_shippingtime
    Public Property products_model
    Public Property group_permission_0
    Public Property group_permission_1
    Public Property group_permission_2
    Public Property group_permission_3
    Public Property group_permission_4
    Public Property products_sort
 
End Class

Und das wäre die ganze Tabelle:

Code: PHP  [Auswählen]

Dim Products() as Product

Was passiert wenn der Klasse nicht alle Daten übergeben werden (können) ist nicht vorhersehbar. Eigenschaften in Klassen zur Laufzeit zu definieren ist aber auch nicht möglich.

Es muss halt irgendwie passen oder passend gemacht werden.

[Matt]

Bin ich der einzige, der der Meinung ist, dass Probleme anderer Sprachen, die mit dem Shop rein gar nichts zu tun haben, Probleme eben dieser Sprachen bleiben und nicht zu Problemen des Shops gemacht werden sollten?

[web4design]

Nein, bist du nicht

[Neo-drexx]

Sei doch einfach ein Fuchs und verhindere das die Spalten gelöscht werden Dann arbeitet deine Mega .Net Klasse zwar mit toten werten aber ist ja genau das was du willst xD

[peterdd]

Dann mach mir mal ein Beispiel, wie Du die Tabelle products abfragst und das Resultset an eine Funktion weitergibst, die den Inhalt des resultsets verarbeiten soll.

Verstehe nicht, wo das ein Problem sein soll.

Code: SQL  [Auswählen]

SELECT * FROM products

bzw. die KundengruppenID hast du schon vorher bestimmt z.B. anhand des aktuellen Kunden und kannst

Code: PHP  [Auswählen]

'group_permission_'.$customers_status

in der Abfrage und Auswertung verwenden.

Ich verwende übrigens * häufig anstatt der Aufzählung der einzelnen Feldnamen im Shop bei einzelnen Tabellenabfragen, weil wir einige zusätzliche Felder haben und so eine Felderweiterung einfacher zu erledigen ist. Performancemäßig kein Problem bei uns.
Bei JOINS muss man ein bisschen aufpassen wegen Feldnamendoppelung, aber kein echtes Problem.

[webald]

Bin ich der einzige, der der Meinung ist, dass Probleme anderer Sprachen, die mit dem Shop rein gar nichts zu tun haben, Probleme eben dieser Sprachen bleiben und nicht zu Problemen des Shops gemacht werden sollten?

Ja und Nein. Für den Shop und seine isolierte Funktion ist es tatsächlich ohne Bedeutung. Will, soll oder muss man den Shop mit anderen System verbinden, sieht es aber schon anders aus.

Sei doch einfach ein Fuchs und verhindere das die Spalten gelöscht werden Dann arbeitet deine Mega .Net Klasse zwar mit toten werten aber ist ja genau das was du willst xD

Du hast dabei vergessen, dass die "toten" Eigenschaften nur auf einer Seite tot sind. Die andere Seite könnte versuchen diese Eigenschaften trotzdem zu verwenden und im schlimmsten Fall die Daten darin verlieren wiel die andere Seite ja tot ist.
Und eine Megaklasse ist das nicht. Bildet man die Bestellungen im Shop als Klasse ab ist das um einiges umfangreicher. Orders enthält die Klassen customers, address_book, orders_products und die wiederrum products und das ist noch total ungenau.

Tatsächlich verstehe ich bis heute nicht, warum man dieses Datenbankdesign jemals verwendet hat, wo man es auch ohne dauernde Änderung an der Datenbank machen kann. Für die meisten scheint da auch Sicherheit keine allzu große Rolle zu spielen, schließlich lauft der Shop ja eigentlich immer mit den maximal möglichen Rechten, die der Provider zur Verfügung stellt (Daten anlegen, Tabellendesign ändern, Tabellen erstellen/löschen, evtl sogar Datenbank erstellen/löschen). Erlaubt Ihr das auch bei der Fibu in der Firma?

Aber ich will hier keinen Monsterthread aufmachen. Ich akzeptier die Sicht der Mehrheit und die Entscheidungen vom Team - und bau drum rum.

Wenn da jetzt keiner mehr was wesentliches dazu hat würde ich sagen EOT. OK?

[Marcus Kreusch]

Nur fürs letzte Wort: DB-Design ist nunmal leider das Stiefkind der allermeisten Entwickler. Da hat Gambio auch noch nichts dran geändert und selbst kommerzielle Projekte wie Shopware sind in der Hinsicht teilweise nicht schön anzusehen.

Von daher gibts von mir den für deine Entscheidung:

Aber ich will hier keinen Monsterthread aufmachen. Ich akzeptier die Sicht der Mehrheit und die Entscheidungen vom Team - und bau drum rum.

[peterdd]

Tatsächlich verstehe ich bis heute nicht, warum man dieses Datenbankdesign jemals verwendet hat, wo man es auch ohne dauernde Änderung an der Datenbank machen kann.

Historisch bedingt sag ich mal.
Dass mit den group_permission_ -Tabellen könnte man wirklich anders lösen, finde ich auch nicht schön.

Aber wenn Hooks/Plugins kommen, dann ist doch klar, dass da auch neue Tabellen und Felder durch den Adminbereich/Plugininstaller erstellt/geändert werden können müssen. Ist doch jetzt auch schon bei Zahlungsmodulen so.

EOT