Чи хороший дизайн таблиці з одним стовпчиком? [зачинено]

Це нормально мати таблицю з лише одним стовпцем? Я знаю, що це технічно нелегально, але чи вважається це поганим дизайном?

Редагувати:

Ось кілька прикладів:

• У вас є таблиця з 50 дійсними кодами штатів США, але вам не потрібно зберігати багатослівні імена штатів.
• Чорний список електронної пошти.

Хтось згадав про додавання ключового поля. Як я це бачу, цей єдиний стовпець БУДЬ первинний ключ.

Так, це, безумовно, хороший дизайн, щоб створити стіл таким чином, щоб зробити його найбільш ефективним. "Поганий дизайн RDBMS", як правило, орієнтований на неефективність.

Однак я виявив, що більшість випадків дизайну однієї колонки можуть отримати користь від додаткового стовпця. Наприклад, у кодах штатів зазвичай може бути вказано повне ім'я держави у другому стовпчику. Або у чорному списку можуть бути пов’язані нотатки. Але якщо ваш дизайн справді не потребує цієї інформації, то цілком нормально мати єдиний стовпчик.

З точки зору relational algebraцього було б одинакове відношення, яке означає " ця річ існує "

Так, добре мати таблицю, що визначає таке відношення: наприклад, визначити домен.

Значення такої таблиці, звичайно, повинні бути природними первинними ключами.

Таблиця пошуку - prime numbersце те, що мені спочатку спадає на думку.

Я використовував їх у минулому. Один мій клієнт хотів автоматично заблокувати будь-кого, хто намагався зареєструватися за номером телефону в цьому великому списку, який у нього був, тому це був лише один великий чорний список.

Якщо в цьому є обґрунтована потреба, то я не бачу проблеми. Можливо, ви просто хочете, щоб список можливостей відображався з якихось причин, і ви хочете мати можливість динамічно змінювати його, але не потрібно пов’язувати його з іншою таблицею.

Один випадок, який я іноді знаходив, - це щось подібне:

Таблиця country_id , містить лише один стовпець з числовим ідентифікатором для кожної країни.

Таблиця country_description , містить стовпчик з ідентифікатором країни, стовпець з ідентифікатором мови та стовпець з локалізованою назвою країни.

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

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

У цьому випадку я думаю, що існування однієї таблиці стовпців виправдано.

Відредаговано у відповідь на коментар: Quassnoi

_{(джерело: ggpht.com )}

У цій схемі я можу визначити іноземний ключ у таблиці company_factories, який не вимагає від мене включати стовпець Мова на стіл, але якщо у мене немає таблиці країни_id, я повинен включити стовпець Мова для таблиці, щоб визначити зовнішній ключ .

Будуть рідкісні випадки, коли таблиця з одним стовпцем має сенс. Я зробив одну базу даних, де список дійсних кодів мови являв собою таблицю з одним стовпцем, що використовується як зовнішній ключ. Не було сенсу мати інший ключ, оскільки сам код був ключовим. А фіксованого опису не було, оскільки описи мовного коду залежать від мови в деяких контекстах.

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

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

Я можу придумати два варіанти використання стовпчикових таблиць OTMH:

1) Елемент даних існує. Часто використовується у випадаючих списках. Також використовується для простих тестів на законність.

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

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

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

-Ал.

Немає проблем, якщо він містить унікальні значення.

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

Я б сказав загалом, так. Не впевнений, навіщо вам потрібен лише один стовпець. Є деякі винятки з цього, які я бачив ефективно. Це залежить від того, що ви намагаєтеся досягти.

Вони не дуже хороший дизайн, коли ви думаєте про схему бази даних, але насправді їх слід використовувати лише як таблиці утиліт.

Я бачив таблиці чисел, які ефективно використовувалися в минулому.

Призначення бази даних - співвідносити інформацію один з одним. Як ви можете це зробити, якщо немає даних, які стосуються?

Можливо, це якась таблиця компіляції (тобто FirstName + LastName + Birthdate), хоча я все ще не впевнений, чому ви хочете це зробити.

EDIT: Я міг бачити використання такої таблиці для простого списку. Це для чого ви використовуєте?

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

Єдиний випадок використання, який я можу скласти, - це таблиця слів, можливо, для гри в слова. Ви отримуєте доступ до таблиці просто для того, щоб переконатися, що рядок - це слово: виберіть слово зі слів, де word =?. Але є набагато кращі структури даних для вмісту списку слів, ніж реляційні база даних.

В іншому випадку, дані в базі даних зазвичай розміщуються в базі даних, щоб скористатися взаємозв'язком між різними атрибутами даних. Якщо ваші дані не мають атрибутів, що перевищують її значення, як розвиватимуться ці відносини?

Тож, хоча це не незаконно, взагалі, напевно, ви не повинні мати таблицю із лише одним стовпцем.

У всіх моїх таблицях є щонайменше чотири технічні поля, послідовний первинний ключ, часові позначки створення та модифікації та булева видалення програмного видалення. У будь-якому чорному списку ви також хочете знати, хто додав запис. Тож для мене відповідь - ні, таблиця з лише одним стовпцем не мала б сенсу, крім випадків, коли щось прототипували.

Так, це прекрасно. але поле ідентифікатора не могло пошкодити це правильно?