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