Я ищу идеи и советы относительно моего проекта. Я хорошо прочитал о табличных отношениях , таких как: один-к-одному , один-ко-многим и многие-ко-многим . Ни один из них не удовлетворяет моим потребностям, так как мне кажется, что я ищу что-то более похожее на многие-к-одному , если только у меня просто нет некоторого понимания этих концепций.
Мне нужно создать 4 отдельные таблицы в моей базе данных и отображают данные из всех 4 таблиц на одной странице. Затем примените к нему фильтры такой природы, чтобы можно было отображать только T1 данные таблицы, T2 данные таблицы ... и так далее. Более того, вы сможете фильтровать предоставленные данные еще дальше. Чтобы уточнить мой вопрос, см. Пример ниже:
T1.events
- id int auto_increment
- перечисление_id int
- введите varchar
- другие поля
T2.deals
- id int auto_increment
- перечисление_id int
- тип varchar
- другие поля
T3.contracts
- id int auto_increment
- перечисление int
- тип varchar
- другие поля
T4.customers
- id int auto_increment
- list_id int
- тип varchar
- другие поля
Мне нужно составить четыре отдельные таблицы, поскольку объем данных, которые они будут содержать, может быть огромным и, следовательно, не следует смешивать в один стол. С другой стороны, мне нужно отобразить все это на одной странице с возможностью применения фильтров. Поэтому я ожидаю иметь четыре 'галочки' : события, сделки, контракты, клиенты. Если один из них отмечен, мы отображаем только данные из этой таблицы, если два отмечены, мы отображаем данные из обеих таблиц и так далее. Более того, после того, как вы отметите, скажем, 'events' , он должен развернуться и показать вам дополнительные возможные фильтры, которые можно применять конкретно к данным, взятым из таблицы 'events' .
Моя идея состояла в том, чтобы создать пятую таблицу:
T5.common_table
- list_id int auto_increment
- id int
- type varchar
Так что гипотетически, если бы мне нужно было вставить данные в 'events' таблицу, процесс go будет выглядеть следующим образом:
- Вставьте данные в таблицу 'events' , за исключением 'перечисление_id' .
- Вставка сгенерированных 'id' и 'type' из 'events' таблицы в 'common_table' -> это будет auto_increment new 'перечисление_id' в 'common_table '.
- Вставить вновь созданный 'перечисление_ид' в 'события' таблицу. (шаг, который мы пропустили в 1.)
Остальные таблицы: T1, T2, T3, T4 будут иметь точно такие же отношения с моей common_table .
Насколько я понимаю, я бы следовал приведенным ниже процедурам, если хотел бы:
Показать все данные -> получить данные из common_table -> получить данные из каждой из таблиц (T1, T2, T3, T4) соответственно с 'isting_ids ', собранными из common_table .
Показать данные одной таблицы -> получить данные из common_table на основе фильтров: type = events -> получить данные из T1.events на основе list_id , собранных из common_table .
Показать две или более таблиц данные -> получить данные из common_table на основе фильтров: тип = события & тип = клиенты -> получить данные от T1.events и T4.customers на основе list_id , собранных из common_table .
Последствия этой идеи:
Всякий раз, когда я хотел бы вставлять или удалять записи в этих таблицах, мне приходилось бы выполнять несколько операций с базой данных, как я должен ссылаться на таблицу. Я работаю с (например: События ) и таблицей, в которой хранятся все возможные списки ( common_table ).
Я не уверен, если такое решение безопасно с точки зрения обслуживания базы данных, имея четыре чрезвычайно огромные таблицы, которые связаны между собой common_table , это хороший подход?
common_table будет состоять, может быть, из трех столбцов, но будет увеличиваться в размерах, поскольку будет хранить ссылки на все четыре таблицы (T1, T2, T3, T4)
Когда я хочу отобразить материал или применить фильтры, я снова должен оперировать минимум двумя-максимум пятью таблицами
Основная причина, по которой мне нужно построить отношения между четыре таблицы являются фильтрами s. Когда я отображаю данные на странице, мне нужно поместить их в список 'one' , хотя ресурс данных - это четыре отдельные таблицы. Сначала я хочу, чтобы он отображался к дате создания , независимо от того, из какой таблицы я взял данные, но я хочу иметь возможность фильтровать эти данные несколькими способами, поэтому я должен иметь возможность ссылки на элементы в каждой из четырех таблиц. Именно здесь вступает common_table , поскольку вместо ссылки на каждую из четырех таблиц я буду ссылаться только на common_table , а затем, основываясь на его данных, перевести его в следующие четыре таблицы. В моей голове это облегчит мою жизнь, например, когда я хочу отобразить материал, я ссылаюсь на common_table , когда я хочу отфильтровать материал, я также ссылаюсь на common_table . Это будет мост между четырьмя таблицами и операциями над ними.
Надеюсь, мое объяснение понятно, я кодирую проект, используя Laravel + Vue но я не думаю, что эта информация была бы актуальной, поскольку этот вопрос имеет несколько иную природу. Буду признателен за любые отзывы, рекомендуемые способы решения проблемы или, возможно, уже одобренные способы ее решения.