Лучшее решение для проектирования базы данных автоматизации? [Дубликат]

Question

Лучшее решение для проектирования базы данных автоматизации? [Дубликат]

0

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

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

Таблица агентств: agency_id | имя | номер телефона | адрес | guides_details (та информация, которая хранится в этом столбце, хранится в формате json, например name, mobile и....)

Теперь мой вопрос: учитывая тот факт, что размер хранилища для проекта не важен (из-за использования на локальном сервере), подходит ли второй метод для крупномасштабного хранения информации (архив)? Или, если есть другой способ заархивировать его, научите меня, пожалуйста.

Mohamad Mahdi Rezaei 03 фев. 2019, в 08:03

Источник

Теги:

php

mysql

database

automation

yii2

database-design

1 ответ

Ещё вопросы

cwarne · Answer 1 · 2019-02-03T04-12-00.000Z

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

Я бы предложил следующие таблицы:

Таблица агентства

agency_id | (любая другая статическая информация)

Таблица сведений об агентстве

Таблица направляющих

guide_id | (любая другая статическая информация)

Таблица подробностей руководства

Тур Стол

tour_id | имя | дата | agency_detail_id | guide_detail_id

Обоснование:

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

Мы разбили детали гида на таблицу, чтобы их можно было легко найти.

tnx, да, это лучший способ, но с этим способом, когда обновляются данные руководства или агентства, история информации о туре будет изменяться,
@MohamadMahdiRezaei Я обновил ответ, чтобы решить, на какую проблему вы ссылаетесь.
Опять же, сложность того, как вы говорите, заключается в сроках его кодирования. Хотя метод json требует гораздо меньше времени, есть ли у метода json и другие недостатки, помимо сложности поиска? С точки зрения скорости запуска программы и ...
@MohamadMahdiRezaei Кроме того, что нет возможности запрашивать его на языке базы данных, нет никакого реального недостатка в JSON в качестве значения столбца. Сложность (в вашем случае) с JSON в качестве подробностей гида заключается в том, что было бы трудно определить, проводил ли один и тот же гид несколько туров, и найти туры, которые делал этот единственный гид. Я решаю эту проблему, имея таблицу руководства отдельно от деталей. Если это не имеет значения для вас, тогда я полагаю, вы можете сохранить его как JSON. С точки зрения скорости, обработка JSON может быть медленнее, чем запросы, использующие уровень вашей базы данных, но это зависит от ваших настроек.