Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Was ist Ihre Meinung zur Verwendung von textuellen Bezeichnern in Tabellenspalten, wenn Sie sich der Datenbank unter Berücksichtigung von Normalisierung und Skalierbarkeit nähern?

Die erste ist stärker normalisiert, wenn auch etwas unvollständig. Es gibt ein paar Ansätze, die Sie wählen können, der einfachste (und genau genommen der "richtigste") benötigt zwei Tabellen, mit der offensichtlichen FK-Einschränkung.

commentid ---- subjectid ----- idType
--------------------------------------
1                22            post
2                26            photo
3                84            reply
4                36            post
5                22            status

idType
------
post
photo
reply
status

Wenn Sie möchten, können Sie ein char(1) oder ähnliches verwenden, um die Auswirkung des varchar auf die Schlüssel-/Indexlänge zu reduzieren oder um die Verwendung mit einem ORM zu erleichtern, wenn Sie eines verwenden möchten. NULL-Werte sind immer lästig, und wenn sie in Ihrem Design auftauchen, sind Sie besser dran, wenn Sie einen bequemen Weg finden, sie zu beseitigen.

Der zweite Ansatz ist einer, den ich bevorzuge, wenn ich mit mehr als 100 Millionen Zeilen zu tun habe:

commentid ---- subjectid
------------------------
1                22    
2                26     
3                84     
4                36     
5                22     

postIds ---- subjectid
----------------------
1                22   
4                36   

photoIds ---- subjectid
-----------------------
2                26    

replyIds ---- subjectid
-----------------------
3                84    

statusIds ---- subjectid
------------------------
5                22     

Es gibt natürlich auch den (leicht denormalisierten) hybriden Ansatz, den ich ausgiebig bei großen Datensätzen verwende, da sie dazu neigen, unsauber zu sein. Geben Sie einfach die Spezialisierungstabellen für die vordefinierten idTypes an, behalten Sie jedoch eine Ad-hoc-IDType-Spalte in der commentId-Tabelle bei.

Beachten Sie, dass selbst der hybride Ansatz nur den doppelten Speicherplatz der denormalisierten Tabelle benötigt; und bietet eine triviale Abfragebeschränkung nach idType. Die Integritätsbeschränkung ist jedoch nicht einfach, da sie eine FK-Beschränkung für eine abgeleitete UNION der Typtabellen ist. Mein allgemeiner Ansatz besteht darin, einen Trigger entweder für die Hybridtabelle oder eine äquivalente aktualisierbare Ansicht zu verwenden, um Aktualisierungen an die richtige Untertyptabelle weiterzugeben.

Sowohl der einfache Ansatz als auch der komplexere Untertyp-Tabellenansatz funktionieren; Trotzdem gilt für die meisten Zwecke KISS, also vermute ich, dass Sie wahrscheinlich einfach eine ID_TYPES-Tabelle, den relevanten FK, einführen und damit fertig sein sollten.