Каков наилучший способ хранения значений по умолчанию в базе данных?

Question

У меня есть несколько таблиц, таких как Buyers, Shops, Brands, Money_Collectors, e.t.c.

Каждый из них имеет значение по умолчанию, например, значение по умолчанию Buyer равно David, значение по умолчанию Shop равно Ebay и т. д.

Я хотел бы сохранить эти значения по умолчанию в базе данных (чтобы пользователь мог их изменить).

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

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

Defaults table:

buyer      shop      brand      money_collector
-----      ----      -----      ---------------
David      Ebay      Dell       NULL   (no default value)

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

Как лучше всего хранить значения по умолчанию?

Answer 1

Просто чтобы прояснить ситуацию.

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

И вот почему ...

"Не следует ли мне беспокоиться о месте при сохранении данных в базе данных?"

Короткий ответ - нет.Более длинный ответ - это то, о чем вам следует беспокоиться, это производительность.Сосредоточение внимания на пространстве приведет вас к очень плохим вещам.

Плохие вещи, которые вы будете делать, если вас беспокоит пространство.

• Вы похороните смысл в Первичных Ключах.т.е. Smart Keys.
• Вы попытаетесь сохранить несколько значений в одном столбце.
• Вы будете слишком мало индексировать
• (Без сомнения, мы могли бы создать список из 50 плохих практик, которые экономят место)

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

Ну, это ONE логический столбец.Он существует в каждом ряду.

Позвольте мне спросить вас об этом.Если вы создали таблицу с 1 столбцом даты и вставили 1 строку, сколько места вы бы использовали на диске?

Если бы вы сказали 7 или 8 байтов, то вы отключились примерно в 1000 раз.

Самая маленькая единица дискового пространства - это блок.Типичные блоки - 8 КБ (могут быть как 2 КБ, так и 32 КБ, в общем (здесь ничего не придираться, фактические пределы не важны))

Допустим, у вас есть блоки 8 КБваш 1 столбец, 1 строка таблицы занимает 8 КБ.Если вы вставите еще 999 строк, он все равно займет 8 КБ. (Опять же, нет придирки, есть накладные расходы на блок и на строку - это пример)

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

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

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

Выпосмотрите, что я говорю.

---

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

1. Там есть логический столбец с именем Default_value
2. Есть таблица без связей с чем-либо, которая называется Default_Values ​​

Вы просите его построить новый магазин с выпадающим списком для «магазина».

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

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

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

---

Технические вещи

Я не парень MySQL, но в Oracle нулевой столбец в конце строки не занимает дополнительного места.В Oracle я бы использовал Varchar2 (1) и пусть 'T' = Default, а остальные оставляем нулевым.Это будет влиять только на использование 1 общего байта, а не на строку.YMMV с MySQL, вы можете задать этот вопрос отдельно, если вы не можете Google ответить.

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

Answer 2

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

Answer 3

То, что вы пытаетесь сохранить, не является метаданными. Прежде всего, поэтому я не буду изобретать внешнее хранилище данных для хранения этих данных. (В сочетании с дополнительным кодом)

Я предполагаю, что у вас есть логика генерации последовательности PK (под вашим контролем). Я назначу магическое число x и вставлю в каждую таблицу запись с _id = x в качестве значения по умолчанию. Поэтому, если вы хотите показать пользователю значение по умолчанию, вы можете обрабатывать запрос единообразно или обрабатывать его в логике приложения во время вставки. Хорошая вещь в этом заключается в том, что у вас есть доступ к значению по умолчанию все время и без написания какой-либо дополнительной логики, и логику для поддержания значения по умолчанию для таблицы можно поддерживать с помощью одного и того же кода (шаблонизатор;) (Из уроков, которые W3c извлек из информации о моделировании схемы XML с использованием DTD.)

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

Answer 4

Вы можете создать таблицу каталога (своего рода таблица метаданных ), содержащую значения по умолчанию в виде строк для нужных столбцов таблицы.Затем вы можете использовать функцию convert для получения соответствующего значения.Ниже приведено примерное определение таблицы (использовалось Transact-SQL ):

create table dbo.cat_default_values
(
    id_column       varchar(30)    not null,
    id_table        varchar(30)    not null,    
    datatype        varchar(30)    not null,    
    value           varchar(100)   not null,    
    f_creation      datetime       not null,
    usr_creation    char(8)        null,    
    primary key  clustered  (id_column, id_table)
)    

declare @defaultValueInt int,
        @defaultValueVarchar varchar(30)

select @defaultValueInt = convert(int, value) 
    from cat_default_values where id_column = "defColumInteger" and id_table = "table1"

select defaultValueVarchar = value 
    from cat_default_values where id_column = "defColumVarchar" and id_table = "table1"

Answer 5

Лучше создать таблицу с двумя столбцами и n строками

Defaults table:
buyer, David
shop, Ebay,
brand, Dell

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