Когда необходимо добавить таблицу в базу данных для поиска значений - PullRequest
0 голосов
/ 25 января 2012

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

сделка

  • TRANSACTION_ID
  • order_id
  • amount_paid
  • payment_status
  • payment_type

Хорошо, допустим, что payment_type может быть одним из трех вариантов («кредитная карта», «прямой кредит» или «международный перевод денег»). В настоящее время для каждой строки таблицы это поле payment_type хранится в виде текста. Теперь лучше сохранить это значение в виде текста или создать для него таблицу поиска и сохранить внешний ключ обратно в таблицу транзакций?

1021 * Е.Г. *

payment_type

  • payment_type_id
  • payment_type_name

сделка

  • TRANSACTION_ID
  • order_id
  • amount_paid
  • payment_status
  • payment_type_id

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

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

Так какая же здесь лучшая практика?

Ответы [ 4 ]

2 голосов
/ 25 января 2012

Используйте «справочную таблицу», когда вам нужно: а) ограничить диапазон значений в столбце и б) изменить диапазон значений во время выполнения.

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

Вы, кажется, смешиваете две разные и не связанные идеи.

  1. Использование «справочных таблиц» (которые я считаю сокращенными для «таблиц и ограничений внешнего ключа»).
  2. Замена текста идентификационными номерами.

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

create table payment_types (
  payment_type varchar (35) primary key
);

insert into payment_types
select distinct payment_type
from transactions;

alter table transactions
add constraint constraint_name
foreign key (payment_type) 
  references payment_types (payment_type);

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

Если вы испытываете желание уменьшить ширину таблицы транзакций, рассмотрите небольшой код CHAR () вместо целого числа. Код, понятный человеку, избегает объединения. В вашем случае я мог бы использовать «cc», «dc» и «it». Но я бы сделал это только после анализа всех известных типов платежей. (Известные бухгалтерам, а не только те, кто известен разработчикам баз данных, и не только те, которые используются в вашей конкретной компании.)

create table payment_types (
  payment_type_code char(2) primary key,
  payment_type_desc varchar(35) not null unique
);

Если код CHAR (2) не покрывает ваши ожидаемые значения, используйте целое число и заплатите цену объединения, чтобы получить читабельные значения.

2 голосов
/ 25 января 2012

необходимо ...

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

если у вас есть простой активный / неактивный столбец или столбец Да / Нет, вы можете просто использовать char (1) и проверочное ограничение или бит, но лучше иметь таблицу поиска, если вы представляете что-то более сложное.

Затем вы можете использовать эту таблицу для ввода формы пользователя (заполнение поля выбора и т. Д.)

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

2 голосов
/ 25 января 2012

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

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

1 голос
/ 25 января 2012

Я вижу несколько преимуществ в использовании справочной таблицы:

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

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

  • Меньший общий размер таблицы transaction.

  • Меньший размер строки таблицы transaction.

  • В этом конкретном случае размер строки также делается постоянным.

  • Различные индексы, включающие payment_type, теперь включают payment_type_id, поэтому они меньше.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...