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

Можно ли иметь таблицу только с одним столбцом? Я знаю, что технически это не незаконно, но считается ли это плохим дизайном?

РЕДАКТИРОВАТЬ:

Вот несколько примеров:

• У вас есть таблица с 50 действующими кодами штатов США, но вам не нужно хранить подробные названия штатов.
• Черный список адресов электронной почты.

Кто-то упомянул добавление ключевого поля. На мой взгляд, этот единственный столбец БУДЕТ первичным ключом.

Да, это, безусловно, хороший дизайн - спроектировать стол таким образом, чтобы он был наиболее эффективным. «Плохой дизайн СУБД» обычно связан с неэффективностью.

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

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

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

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

В prime numbersпервую очередь мне приходит в голову справочная таблица .

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

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

Один случай, который я иногда обнаруживал, выглядит примерно так:

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

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

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

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

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

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

_{(источник: ggpht.com )}

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

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

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

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

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

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

Например. двухбуквенные аббревиатуры штатов США; Почтовые индексы, на которые мы отправляем; слова законные в Scrabble; и т.п.

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

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

-Ал.

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: я мог видеть использование такой таблицы для простого списка. Это то, для чего вы его используете?

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

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

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

Таким образом, хотя это и не является незаконным, в целом вам, вероятно, не следует иметь таблицу с одним столбцом.

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

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