Welcher Weg ist besser, benutzerdefinierte Felder in einer Webanwendung zu implementieren?

Question

Ich habe eine selbst erstellte Webanwendung in PHP und MySQL. Die vielen verschiedenen Clients, die mein System verwenden, möchten Entitäten mit benutzerdefinierten Feldern erweitern. Jeder Kunde möchte seine eigenen zusätzlichen Daten speichern, also sollte dies dynamisch geschehen.

Zum Beispiel client1 möchte die „Farbe“ Eigenschaft, um ihre Produkte hinzuzufügen, client2 ein Feld „safety_level“ für ihre Produkte genannt werden sollen.

Ich möchte eine Methodik, die nicht nur für Produkte, sondern auch für Benutzer und andere Entitäten angewendet werden kann.

Hier gibt es 2 Möglichkeiten ich die optimale gefunden, aber nicht entscheiden kann, was man am effektivsten:

OPTION 1: Für jede Entität Ich mache eine [entityname]_customfields Tabelle, in der ich den Laden zusätzliche Feldwerte in 1: 1. z.B .:

+---------------------------------------------+ 
|products_custom_fields      | 
+---------------------------------------------+ 
|product_id (PK and FK related to products.id)| 
|safety_level         | 
|some_other_fields       | 
+---------------------------------------------+ 

pro: Diese Tabelle kann nicht mehr Datensätze als die Objekt-Tabelle hat (in diesem Fall der Produkte), die weniger Datensätze und es ist ganz einfach zur Übersicht bedeutet.

con: das Hinzufügen neuer Felder oder das Löschen alter Felder erfordert DDL-Abfragen. Ich möchte DDL nicht an Benutzer weitergeben ... nicht einmal an Benutzer mit Administratorberechtigungen.

Option 2: [entity]_custom_field_values wird N: 1 haben Beziehungen zu [entity] Tabelle. Jede Zeile enthält den Typ des benutzerdefinierten Felds und den Wert selbst. In diesem Fall benötigen wir eine andere Tabelle, die die benutzerdefinierten Feldtypen enthält. zB:

benutzerdefinierte Feldwerte:

+----------------------------------------------------------------------+ 
|products_custom_field_values           | 
+----------------------------------------------------------------------+ 
|custom_field_id              | 
|custom_field_type (FK product_custom_field_types.custom_field_type_id)| 
|value                 | 
+----------------------------------------------------------------------+ 

benutzerdefinierte Feldtypen:

+---------------------------------------------------------+ 
|products_custom_field_types        | 
+---------------------------------------------------------+ 
|custom_field_type_id (PK AUTO_INCREMENT)     | 
|product_id (FK related to products.id)     | 
+---------------------------------------------------------+ 

pro: Verwaltung Felder ist einfach, erfordert keine Tabellenstrukturen

verändern con: mehr Datensätze, alle Arten von benutzerdefinierten Feldwerten in einem großen Durcheinander ... was nicht notwendig ist falsch, weil das ist der Punkt von MySQL, um nützliche Daten aus einem großen Durcheinander zu extrahieren. Die Frage ist was ist mit Effizienz und Leistung?

Answer 1

Wenn es sich um ein Unternehmensprojekt handelt, folgen Sie den Standards früherer Projekte.

Werfen Sie einen Blick auf Konventionen wie die ungarische Notation, die sinnvoller wäre als die Wiederholung eines Präfixes. Es ist auch wahrscheinlicher, dass Ihr Modellname Ihr Tabellenname ist.

Auch wenn Sie planen, ORM zu verwenden, könnten sie auch einige Best Practices haben.

https://en.wikipedia.org/wiki/Hungarian_notation

Answer 2

_{Hinweis: dieses Thema tatsächlich in der "SQL Antipatterns" bedeckt, die ich Ihnen dringend empfehlen, lesen}

Ich bin eine faule Person, die, dass ich Mittel neigen dazu, YANGI auf meinen Code anzuwenden. Das ist mein Ansatz.

So. Nehmen wir an, dass es zwei Gruppen von Produkten:

ProductFoo  ProductBar 
- productID  - productID 
- name   - name 
- price   - price 
- color   - supply 
- weight   - manufacturerID 
        - safety 

In diesem Fall gibt es drei gemeinsame Elemente sind, die in der Haupt Products Tisch gehen. Und die benutzerdefinierten Parameter würden mit Tabelle Vererbung (es ist eine Sache, google es) gespeichert werden. Also würden Sie im Grunde mit drei Tabellen enden: Products, ProductsFoo und ProductsBar, wobei Products Tabelle ein "type" Feld hat und beide der "untergeordneten Tabellen" einen fremden Schlüssel productID haben, der auf seine Elterntabelle verweist.

Das ist, wenn Sie zur Entwicklungszeit wissen, welche "benutzerdefinierten Felder" jeder Client haben möchte.

Nun nehmen wir an, Kunden sind schwierig und wollen benutzerdefinierte Felder erstellen, wann immer sie sich danach fühlen.

In diesem Fall würde ich einfach ein Products.data Felder erstellen, die ein JSON mit allen benutzerdefinierten Attributen für jedes Produkt enthält. Und nur "extrahieren" spezielle Attribute zu einer erbenden Tabelle, wenn der Client nach diesem benutzerdefinierten Attribut suchen will (es gibt keine vernünftige Möglichkeit, JSON zu indizieren, wenn Clients nach ihrem neuen "wallywanker" -Attribut suchen wollen).

Sie enden mit dem gleichen Grundstruktur, aber die „Untertabellen“ nur die Attribute enthalten, die erwartet werden,

durchsuchbar sein Ich hoffe, dieser Sinn.