Каково ваше мнение об использовании текстовых идентификаторов в столбцах таблицы при подходе к базе данных с учетом нормализации и масштабируемости?

Question

Какая структура таблицы считается лучше нормализованной?

, например

Примечание: idType сообщает, на какой вещи произошел комментарий, а subjectid - это идентификатор элемента комментария

с использованием idType идентификатора субъекта с текстовым именем.

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

По сравнению с этим.

commentid ---- postid ----- photoid-----replyid
-----------------------------------------------
1                22          NULL        NULL
2                NULL         56         NULL
3                23          NULL        NULL
4                NULL        NULL        55
5                26          NULL        NULL

Я смотрю на них обоихи я не думаю, что в первой таблице я смогу связать его с ограничением внешнего ключа = ((т. е. комментарий удаляется, если пост или фотография удалены), где, как и во второй, это возможно, как бы выподходить к аналогичной проблеме, имея в виду, что база данных должна расширяться со временем, а целостность данных также важна =).

Спасибо

Answer 1

Первый более нормализован, если немного неполон. Есть несколько подходов, которые вы можете использовать, самый простой (и, строго говоря, самый «правильный») потребует две таблицы с очевидным ограничением FK.

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

idType
------
post
photo
reply
status

Если хотите, вы можете использовать символ (1) или аналогичный для уменьшения влияния varchar на длину ключа / индекса или для облегчения использования с ORM, если вы планируете его использовать. NULL всегда надоедают, и если вы начнете видеть их появление в вашем дизайне, вам будет лучше, если вы сможете найти удобный способ их устранения.

Второй подход, который я предпочитаю при работе с более чем 100 миллионами строк:

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     

Конечно, существует также (слегка денормализованный) гибридный подход, который я широко использую с большими наборами данных, так как они имеют тенденцию к загрязнению. Просто предоставьте таблицы специализации для предопределенных идентификаторов idTypes, но сохраните столбец adhoc idType в таблице commentId.

Обратите внимание, что даже для гибридного подхода требуется только двукратное пространство денормализованной таблицы; и обеспечивает тривиальное ограничение запроса с помощью idType. Ограничение целостности, однако, не является прямым, будучи ограничением FK для производного UNION таблиц типов. Мой общий подход заключается в использовании триггера либо в гибридной таблице, либо в эквивалентном обновляемом представлении для распространения обновлений на правильную таблицу подтипов.

Работает как простой, так и более сложный подход к таблицам подтипов; тем не менее, для большинства целей применяется KISS, так что просто я подозреваю, что вам, вероятно, следует просто ввести таблицу ID_TYPES, соответствующий FK и покончить с этим.