Является ли таблица с одним столбцом хорошим дизайном?
Можно ли иметь таблицу с одним столбцом? Я знаю, что это технически не незаконно, но считается ли это плохим дизайном?
РЕДАКТИРОВАТЬ:
Вот несколько примеров:
- У вас есть таблица с 50 действительными кодами штатов США, но вам не нужно хранить подробные названия штатов.
- Черный список адресов электронной почты.
Кто-то упомянул добавление ключевого поля. На мой взгляд, этот единственный столбец был бы первичным ключом.
15 ответов
Да, конечно, это хороший дизайн, чтобы проектировать стол таким образом, чтобы он был максимально эффективным. "Плохой дизайн СУБД" обычно связан с неэффективностью.
Тем не менее, я обнаружил, что в большинстве случаев одного столбца может быть полезным дополнительный столбец. Например, коды состояний обычно могут содержать полное имя государства, указанное во втором столбце. Или черный список может иметь связанные заметки. Но если вашему дизайну действительно не нужна эта информация, тогда вполне нормально иметь один столбец.
С точки зрения relational algebra это было бы одинарное отношение, означающее "эта вещь существует"
Да, хорошо иметь таблицу, определяющую такое отношение: например, чтобы определить домен.
Значения такой таблицы должны быть естественными первичными ключами, конечно.
Таблица соответствия prime numbers это то, что приходит мне в голову первым.
Я использовал их в прошлом. Один мой клиент хотел автоматически заблокировать любого, кто пытался зарегистрироваться с помощью номера телефона в этом большом списке, который у него был, так что это был только один большой черный список.
Если это действительно необходимо, то я не вижу проблемы. Может быть, вам просто нужен список возможностей для отображения по какой-то причине, и вы хотите иметь возможность динамически изменять его, но вам не нужно связывать его с другой таблицей.
Один случай, который я обнаружил, иногда выглядит примерно так:
Таблица country_id, содержит только один столбец с числовым идентификатором для каждой страны.
Таблица country_description, содержит столбец с идентификатором страны, столбец с идентификатором языка и столбец с локализованным названием страны.
Таблица company_factories, содержит информацию о каждой фабрике компании, в том числе о стране, в которой находится.
Поэтому для поддержания согласованности данных и данных, не зависящих от языка, в таблицах база данных использует эту схему с таблицами, имеющими только один столбец, чтобы разрешить использование внешних ключей без языковых зависимостей.
В этом случае я считаю существование таблицы с одним столбцом оправданным.
Отредактировано в ответ на комментарий: Quassnoi
http://lh5.ggpht.com/_7ON9I_WO6GU/SikFHBtzcxI/AAAAAAAAA-4/6MrVUCHGoWU/s800/taules.png
В этой схеме я могу определить внешний ключ в таблице company_factories, который не требует, чтобы я включил в таблицу столбец Language, но если у меня нет таблицы country_id, я должен включить в таблицу столбец Language, чтобы определить внешний ключ,
Были бы редкие случаи, когда таблица с одним столбцом имеет смысл. Я создал одну базу данных, в которой список допустимых кодов языков представлял собой таблицу из одного столбца, которая использовалась в качестве внешнего ключа. Не было никакого смысла иметь другой ключ, так как сам код был ключом. И не было фиксированного описания, так как описания языкового кода в некоторых контекстах могут отличаться в зависимости от языка.
В общем, любой случай, когда вам нужен авторитетный список значений, которые не имеют никаких дополнительных атрибутов, является хорошим кандидатом для таблицы с одним столбцом.
В основном я видел это в таблицах типов поиска, таких как таблица состояний, которую вы описали. Однако, если вы сделаете это, обязательно установите столбец в качестве первичного ключа для обеспечения уникальности. Если вы не можете установить это значение как уникальное, вам не следует использовать один столбец.
Я все время использую таблицы с одним столбцом - конечно, в зависимости от того, использует ли дизайн приложения базу данных. После того, как я выдержал накладные расходы на создание соединения с базой данных, я по возможности помещал все изменяемые данные в таблицы.
Я могу вспомнить два варианта использования одностолбцовых таблиц OTMH:
1) Элемент данных существует. Часто используется в выпадающих списках. Также используется для простых тестов легитимности.
Например. двухбуквенные аббревиатуры штатов США; Почтовые индексы, которые мы отправляем; слова законно в скрэббл; и т.п.
2) Разреженный двоичный атрибут, т. Е. В большой таблице, двоичный атрибут, который будет истинным только для очень немногих записей. Вместо добавления нового логического столбца я мог бы создать отдельную таблицу, содержащую ключи записей, для которых атрибут имеет значение true.
Например. сотрудники с неизлечимой болезнью; банки с 360-дневным годом (большинство используют 365); и т.п.
-Аль.
Я бы сказал в общем да. Не уверен, почему вам нужен только один столбец. Есть некоторые исключения из этого, которые, как я видел, используются эффективно. Это зависит от того, чего вы пытаетесь достичь.
Они не очень хороший дизайн, когда вы думаете о схеме базы данных, но на самом деле должны использоваться только в качестве служебных таблиц.
Я видел таблицы чисел, которые эффективно использовались в прошлом.
Да, если поле является первичным ключом, как вы и сказали. Причина в том, что если вы вставите повторяющиеся данные, эти строки будут доступны только для чтения. Если вы попытаетесь удалить одну из строк, которые дублируются. это не будет работать, потому что сервер не будет знать, какую строку удалить.
Цель базы данных - связать фрагменты информации друг с другом. Как вы можете сделать это, когда нет данных, к которым можно было бы обратиться?
Может быть, это какая-то таблица компиляции (например, FirstName + LastName + Birthdate), хотя я до сих пор не уверен, почему вы захотите это сделать.
РЕДАКТИРОВАТЬ: я мог видеть, используя этот вид таблицы для простого списка какой-то. Это то, что вы используете для этого?
Единственный вариант использования, который я могу придумать, - это таблица слов, возможно, для игры в слова. Вы получаете доступ к таблице только для проверки того, что строка является словом: выберите слово из слов, где слово =? Но есть гораздо лучшие структуры данных для хранения списка слов, чем реляционная база данных.
В противном случае данные в базе данных обычно помещаются в базу данных, чтобы воспользоваться взаимосвязями между различными атрибутами данных. Если ваши данные не имеют атрибутов, выходящих за рамки их значения, как будут развиваться эти отношения?
Поэтому, хотя это и не незаконно, в общем случае у вас, вероятно, не должно быть таблицы с одним столбцом.
Все мои таблицы имеют по крайней мере четыре технических поля, серийный первичный ключ, метки времени создания и изменения и логическое удаление. В любом черном списке вы также захотите узнать, кто добавил запись. Поэтому для меня ответ - нет, таблица с одним столбцом не имеет смысла, за исключением случаев, когда что-то создаете.
Да, это прекрасно. но поле идентификатора не может повредить это правильно?