Комментарии для всего сайта с различными типами страниц и особыми требованиями

Question

Я заинтересован в разработке базы данных (ну, на самом деле, меня интересует только одна таблица) для сайта со следующими требованиями:

1. Существует страница items, в которой перечисленыПредметы.items.xyz?id=t отображает элемент с идентификатором t.Мне нужно, чтобы идентификаторы предметов были последовательными.Первый элемент имеет идентификатор 1, второй идентификатор 2 и так далее.Каждая страница элемента имеет комментарии к этому элементу.
2. Существуют и другие страницы, например objects, где objects.xyz?id=t отображает объект с идентификатором t.Идентификаторы здесь не обязательно должны быть последовательными (и они могут перекрываться с идентификаторами предметов, но это нормально, если вы предлагаете что-то, что заставляет их не перекрываться).У них также есть комментарии.

Мой вопрос: как спроектировать таблицу Comments?Если у меня есть EntityID, представляющий страницу, на которой должен отображаться комментарий (будь то страница элемента или страница объекта), то я должен сделать так, чтобы ItemID никогда не перекрывал ObjectID, делаявсе ObjectID начинаются, скажем, с 10 ⁹ и с использованием таблицы GUID?(ItemIDs увеличиваются очень медленно).Является ли это приемлемой практикой?

Прямо сейчас я делаю это, имея в каждом комментарии по несколько булевых полей: IsItem, IsObjectType1, IsObjectType2, ..., что позволяет мнезнать, где каждый комментарий должен отображаться.Это не так уж плохо, так как у меня есть только несколько объектов, но это похоже на уродливый хак.

Как лучше всего это сделать?

Answer 1

Я вижу три решения (при условии, что невозможно или нежелательно поместить страницы и объекты в одну таблицу).Либо:

1. Сообщите комментарий, к которому он относится, указав два столбца: PageId и ObjectId.Таким образом, вы также можете присвоить этим столбцам внешние ключи для соответствующих таблиц и добавить соответствующие индексы.

2. Представьте таблицу «Entity», которая имеет уникальный идентификатор, PageId и ObjectId.Любой из столбцов не является обязательным, конечно, должен быть заполнен ровно один из них, а не 0 или оба.Таким образом, вы перемещаете весь потенциальный мусор наличия отдельных сущностей в эту таблицу, не загрязняя таблицу комментариев, которая должна содержать только комментарии.Вы изолируете беспорядок.

3. Создайте таблицу связей между комментариями и объектами и другую таблицу между комментариями и объектами.Предметы и объекты совершенно не связаны, и вам не нужно загрязнять таблицу комментариев множеством значений NULL в нескольких столбцах.Когда вы создаете комментарий, вы решаете, будет ли он ссылаться на Item или Object, вставляя ссылку в ItemComments или ObjectComments.Чтение комментариев для элемента или объекта - это вопрос двух простых объединений.

Таблица комментариев может содержать только один EntityId, который ссылается на Id в таблице Entity.

Большим преимуществом этого подхода является двоякое:
a) Вы также можете связать другие вещи с одной и той же таблицей, что без особых хлопот.
b) Вы можете добавлять другие виды сущностей, и они будут автоматически поддерживать Комментариии другие вещи, которые вы можете добавить, как указано в a).