Задать вопрос
Decadal

Decadal

Ответы пользователя по тегу Проектирование баз данных

  • Существуют ли в каких-либо СУБД такое понятие, как условный уникальный индекс?

    Decadal
    @Decadal
    Вы можете сделать Composite Unique Key по полям addr, city_id или addr и group_id
    Например:
    ALTER TABLE Line ADD UNIQUE KEY `uk_address_city` (addr, group_id);


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

  • В какой таблице лучше ставить внешний ключ при связи 1 к 1?

    Decadal
    @Decadal
    Вам нужно определить, какая сущность главная, а какая второстепенная для вашей программы. Как это будет выглядеть? Сначала заводится список тренеров а потом к ним крепятся команды? Или, наоборот, есть список команд и нужно создать им тренера? А может, это равнозначные сущности, и вы хотите иметь возможность завести список команд и список тренеров независимо друг от друга, а уже потом проставить связи?
    Ставьте внешний ключ той сущности, которая не будет иметь множественной связи с большей вероятностью.
    К примеру, если это соц сеть для тренеров, то вероятнее всего, тренер сможет добавлять список команд которых он тренировал. И тогда trainer_id пригодится в teams.
    Но если ваша соцсеть вырастет и там будет база команд, которые тренер сможет выбрать из выпадающего списка (т.е. у команд тоже может быть много тренеров), то придется делать M:N. Ваш случай связи 1:1 возник только потому что ваше приложение еще недостаточно развилось.

    Также не забудьте что 1 к 1 реализуется назначением UNIQ ограничения на внешний ключ. Иначе это 1 ко многим.
    Ответ написан
    2 комментария
    2 комментария

  • Нужна ли денормализация?

    Decadal
    @Decadal
    Нужно ли, по-хорошему, в таблице заказов orders(id, client_id, ...) дублировать все поля (id, client_id, client_first_name, client_last_name, ...)? С одной стороны, так заказ фиксируется неизменным навсегда, даже в случае удаления клиента или изменения его данных. Но с другой - кошмарная избыточность, ведь в таблице заказов может быть еще другие связи 1 к 1 и в итоге полей будет миллион.


    У вас не должно быть удалений клиентов. Функцию удаления достаточно реализовать через soft delete (флаг deleted_at).
    Кстати а для заказа есть смысл делать другую таблицу. Historical_order_client - на тот случай если нужно запоминать факт с каким телефоном и фамилией был клиент (фамилии и телефоны меняются, а надо ли их менять в заказах - вам виднее).

    Или может делать суммирующее поле типа orders(id, client_id, client_info (Иванов И. пасп. 0301 333333, тел 8999999999)?

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

    Или может делать доп поле orders (client_id, client_data), где в client_data запихать json записи из client, что в случае чего восстановить запись.

    не стоит
    Ответ написан
    5 комментариев
    5 комментариев