Удаление таблицы без уникального индекса
Рассмотрим следующие таблицы:
CREATE TABLE "lemmings"
(
"id" bigserial,
"name" varchar(255) NOT NULL,
PRIMARY KEY ("id")
);
CREATE TABLE "speeches"
(
"id" bigserial,
"title" varchar(255) NOT NULL,
"year" integer NOT NULL,
PRIMARY KEY ("id")
);
Никаких других таблиц в этой схеме не существует.
Таблица lemmings не имеет уникальных индексов. Это значит, что у двух леммингов может быть одинаковый name.
Лемминг может произносить несколько речей, а речь могут произносить несколько леммингов.
Уточним: лемминг может произносить более одной речи, а речь может произносить более чем один лемминг.
Учитывая вышесказанное, считаю, что таблица lemmings избыточна, и следует предпринять следующие шаги:
- Уберите таблицу
lemmings. - Добавьте столбец
lemming_namesв таблицуspeeches.
Верны ли мои рассуждения?
В таблице леммингов есть только столбцы: id, name. Меня беспокоит то, что таблица леммингов с возможными повторяющимися именами может оказаться бесполезной на практике.
Могут ли они иметь одно и то же имя, как люди? Может ли у лемминга быть дата рождения, чтобы отличать их, или какая-то другая уникальность?
Могут, но я не уверен, насколько полезным будет имя в специальной таблице, стихи внутри столбца массива. Не существует понятия уникального лемминга, имеющего имя. Имя лемминга, по-видимому, по сути является речевыми данными.
В этом примере нет никаких других свойств лемминга, кроме имени.
Извините, но вопрос неясен. Как speeches относится к lemmings?
В вопросе, который я подробно описал: лемминги могут произносить несколько речей, а речь могут произносить несколько леммингов.
Подчеркну: мы не знаем о леммингах ничего, кроме их названий.
Какая речь принадлежит какому леммингу?
Почему два лемминга с одинаковым именем — это два разных лемминга, а не один лемминг с двумя рекордами?
@Laurenz Albe Я прояснил взаимосвязь, надеюсь, это поможет: лемминг может произнести несколько речей, а речь может произнести несколько леммингов. Таким образом, лемминг может произносить более одной речи, а речь может произносить более чем один лемминг.
Похоже, вам не следует его удалять, вместо этого создайте таблицу соединения lemming_speech (lemming_id bigint REFERENCES lemmings (id), speech_id bigint REFERENCES speeches (id), PRIMARY KEY (lemming_id, speech_id)) Столбец массива является одновременно плохой нормализацией и не будет работать здесь из-за того, что lemming сущности существуют независимо от speech.
@Frank Heikens По сути, я считаю, что без каких-либо уникальных полей (за исключением идентификатора) таблица леммингов была бы бесполезна, поскольку мы не могли бы различить эти два сценария.
@Charlieface, применима ли та же логика к твоему предложению? Насколько я понимаю, таблица леммингов по-прежнему не будет уникальной, кроме идентификатора.
Это отдельная проблема: для этого вы можете просто добавить уникальное ограничение/индекс в name, чтобы обеспечить это. Суррогатный первичный ключ id по-прежнему полезен, поскольку varchar(255) очень широк для первичного ключа, поэтому имеет смысл сохранить name в качестве вторичного уникального ключа.
В вопросе я подробно пояснил, что для таблицы леммингов не существует уникальных ограничений; к сожалению, это часть сценария. Учитывая это, я не уверен, что сущность лемминга можно идентифицировать с помощью поля имени, поэтому я не уверен, что таблица соединений поможет.
Вы не понимаете, что я говорю. Я не прошу словесного описания, я спрашиваю, где в базе данных я могу увидеть, какая отдельная lemming строка принадлежит каким speech строкам и наоборот? Без этой информации вопрос неясен.
Других таблиц не существует, только указанные. Я добавил это в вопрос, спасибо за подсказку.
Вы, кажется, путаете разные вопросы: как моделировать отношения и как моделировать леммингов. Подтверждая @Charlieface, если в речи может быть несколько леммингов, а у лемминга может быть несколько речей, то ЕДИНСТВЕННЫЙ способ смоделировать это - иметь таблицы леммингов и речей, а также таблицу пересечений между ними. Как моделировать таблицу леммингов — это отдельная тема.
Я считаю, что если лемминга невозможно точно смоделировать, то такой связи не должно существовать.
Поскольку вы не можете (не должны) иметь несколько значений (имен леммингов) в одном столбце, как еще вы собираетесь это смоделировать? Тот факт, что у вас есть только атрибут имени для леммингов, не влияет на то, как вы моделируете отношения M:M.
Большое спасибо, не могли бы вы предоставить это в качестве ответа? Спасибо за вашу помощь всем! Теперь я понимаю, что мне нужно сохранить таблицу леммингов и использовать соединительную таблицу; таблица леммингов неправильно моделирует сущность и должна быть уточнена, но ее удаление означало бы нарушение 1NF. Я мог бы, например, добавить еще один столбец с леммингами, чтобы обеспечить уникальность. По сути, моя таблица леммингов несколько неполна.
Ответы 1
Поскольку вы не можете (не должны) иметь несколько значений (имен леммингов) в одном столбце, вы смоделировали это с помощью таблицы пересечений? Тот факт, что у вас есть только атрибут имени для леммингов, не влияет на то, как вы моделируете отношения M:M.
Вам понадобится таблица, которая показывает идентификатор лемминга для идентификатора речи. Зависит от того, сколько данных о лемминге вы храните, относящихся к каждому запросу.