Является ли таблица с одним столбцом хорошим дизайном? [закрытый]

С точки зрения relational algebra Это будет унарное отношение, означающее "эта вещь существует"

Да, это нормально иметь таблицу, определяющую такое отношение: например, чтобы определить домен.

значения такой таблицы должны быть естественными первичными ключами, конечно.

таблица подстановки prime numbers это то, что приходит в голову в первую очередь.

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

Если есть действительная необходимость в этом, то я не вижу проблемы. Возможно, вам просто нужен список возможностей для отображения по какой-то причине, и вы хотите иметь возможность динамически изменять его, но не нужно связывать его с другой таблицей.

одно дело, что я нашел иногда что-то вроде этого:

стол countries_id, содержит только один столбец с числовым идентификатором для каждой страны.

стол countries_description, содержит столбец с идентификатором страны, столбец с идентификатором языка и столбец с локализованным именем страны.

стол company_factories, содержит информацию для каждой фабрики компании, включая страну в которой расположенный.

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

в этом случае я думаю, что существование одной таблицы столбцов оправдано.

редактировать в ответ на комментарий: Quassnoi

http://lh5.ggpht.com/_7ON9I_WO6GU/SikFHBtzcxI/AAAAAAAAA-4/6MrVUCHGoWU/s800/taules.png

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

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

В общем случае, в любом случае, когда вам нужен авторитетный список значений, которые не имеют никаких дополнительных атрибуты-хороший кандидат для таблицы с одним столбцом.

Я использую таблицы с одним столбцом все время-в зависимости, конечно, от того, использует ли дизайн приложения уже базу данных. После того, как я перенес накладные расходы на создание подключения к базе данных, я помещаю все изменяемые данные в таблицы, где это возможно.

Я могу думать о двух вариантах использования одностолбцовых таблиц OTMH:

1) данных. Часто используется в выпадающих списках. Также используется для простых тестов легитимности.

например. двухбуквенные сокращения штатов США; Zip коды, которые мы отправляем по; слова юридический в Эрудит; и т. д.

2)разреженный двоичный атрибут, т. е., в большой таблице, двоичный атрибут, который будет верен только для очень немногих записей. Вместо добавления нового логического столбца я мог бы создать отдельную таблицу, содержащую ключи записей, для которых атрибут имеет значение true.

например. сотрудники, которые имеют болезнь; банки с 360-дневного года (наиболее использовать 365); и т. д.

- Al.

нет проблем, пока он содержит уникальные значения.

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

Я бы сказал Вообще, да. Не знаю, почему вам нужен только один столбец. Есть некоторые исключения из этого,что я видел эффективно используется. Это зависит от того, чего вы пытаетесь достичь.

Они не очень хороший дизайн, когда вы думаете о схеме базы данных, но на самом деле должны использоваться только в качестве служебных таблиц.

Я видел количество таблиц используется эффективно в прошлом.

цель базы данных состоит в том, чтобы связать части информации друг с другом. Как вы можете это сделать, когда нет данных, к которым можно было бы относиться?

может быть, это какая-то таблица компиляции (т. е. FirstName + LastName + Birthdate), хотя я все еще не уверен, почему вы хотите это сделать.

EDIT: я мог видеть, используя этот вид таблицы для простого списка какой-то. Это то, для чего вы его используете?

да, если это поле является первичным ключом, как вы сказали. Причина в том, что при вставке повторяющихся данных эти строки будут только для чтения. При попытке удалить одну из строк, которые дублируются. это не будет работать, потому что сервер не будет знать, какую строку удалить.

единственный вариант использования, который я могу себе представить, - это таблица слов, возможно, для игры в слова. Вы получаете доступ к таблице только для того, чтобы убедиться, что строка-это слово: выберите слово из слов, где word = ?. Но есть гораздо лучшие структуры данных для хранения списка слов, Чем реляционных

все мои таблицы имеют по крайней мере четыре технических поля, последовательный первичный ключ, временные метки создания и модификации и мягкое удаление boolean. В любом черном списке вы также захотите узнать, кто добавил запись. Поэтому для меня ответ-нет, таблица только с одним столбцом не будет иметь смысла, кроме как при прототипировании чего-то.

Да, это совершенно нормально. но поле ID не может повредить его правильно?