PavelUstyugov
@PavelUstyugov
php

Это плохо когда много таблиц на в базе данных или в одну лучше пихать?

Появились разногласия с коллегой. Он предлагает многие вещи держать в одной таблице, например, телефоны, соц сети, email, адреса, картинки, документы. И просто завести поле "Вид" чтоб по ниму ориентироваться. И аргументирует это тем "зачем таблицы плодить".

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

Если это емейл, то он хранится отдельно. Для него свой валидатор на фронтэнде. Свой функционал по извлечения емейлов, рассылка и т.п.

А каждый раз в выборках прописывать условия мне кажется это портит разработчику жизнь. Или все же нужно стремиться все упаковывать в одну таблицу?
  • Вопрос задан
  • 704 просмотра
Пригласить эксперта
Ответы на вопрос 7
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Вам с коллегой стоит познакомиться с реляционной теорией и нормальными формами.
Ответ написан
Stalker_RED
@Stalker_RED
Разные сущности лучше в разные таблицы.

При этом стоит как-то разделять что для вашей бизнес-логики является сущностью, а что не очень.

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

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

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

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

Осталось вам решить, где именно проходит грань "необходимое/лишнее".
Ответ написан
kocherman
@kocherman
Сколько таблиц по-барабану. Вопрос в том сколько и какие будут индексы. А вот фотографии в БД лучше не хранить, для этого проще использовать отведённую папочку на сервере.
Ответ написан
@McBernar
Серьезно? Отдельная таблица для хранения почты пользователя?

Почитайте про ORM, что ли.
Ответ написан
LaRN
@LaRN
Senior Developer
У разных объектов разный набор атрибутов.
Если хранить все в одной таблице, может быть много пустых полей в записи из-за того, что типу объекта в текущей записи не нужны многие из существующих полей.
Зачем хранить пустоту?
А ещё в такой ситуации может появиться желание заюзать имеющиеся неиспользуемые поля не по назначению (а типа чтобы новых полей не добавлять) в итоге в таблице будет со временем бардак.
Лучше для каждого объекта свою таблицу конструировать, так и компактнее будет и будет возможность для каждого вида объекта добавить только нужные для работы с ним индексы, да и при изменении полей текушей таблицы другие объекты в других таблицах не меняются и меньше вероятность регресса.
Ответ написан
@nono
Из своего опыта скажу, что реализация один класс = одной таблицы не всегда эффективно. К примеру, сущность "сотрудник", у которой есть Ф.И.О., СНИЛС, номера телефонов и т.д. Эта одна сущность, у которой Ф.И.О и СНИЛС имеют текстовые поля, а номера телефонов (к примеру) список. Я бы реализовал в двух таблицах: Ф.И.О. и СНИЛС в одной таблице, так как это уникальные значения; телефоны в другой (привязанной с первой по внешнему ключу), так как у сотрудника могут быть несколько телефонов.
Если необоснованно плодить таблицы, то это сказывается на производительности, запрос к нескольким таблицам выполняется дольше, так как необходимо связывание по ключам.
Запихивать все в одну таблицу тоже не выход. К примеру, ведется запись сотрудников, у которых указываются должности. Если должности выделить в отдельную таблицу, то образуется своего рода уникальность. Если придется переименовать должность, то ты это делаешь в одной записи, иначе - надо будет перебирать всех сотрудников и менять им должность.
Конечно, если количество записей не большое, то на производительности не заметешь.
Ответ написан
@uaggster
Если вы планируете базу микрокопического размера - на пару десятков - пару сотен тысяч записей (в самой большой таблице) - делайте как вам удобнее.
Одна сущность - один класс - одна таблица, линкью, энтити фреймворк и всякие такие приятные штуки.
Однако, если ваша база должна хранить сколько нибудь отличное от нуля количество информации (ну, хотя бы информацию о миллионе объектов), либо в нее должны одновременно обращаться сколько нибудь значительное количество пользователей, ну, хотя ты полсотни - забудьте про програмистском подходе вообще. Только голый SQL, хранимые процедуры, общение с сервером в стиле - "конкретный вопрос - конкретный ответ", никаких "облегчающих жизнь" фреймворков, только голый adodb, только хардкор. Никаких абстракций поверх sql кода. Никаких нерегламентированных, а тем более сгенерированных фреймворками текстов запросов прилетающих из приложения. Только хранимые процедуры, на сервере бд, в виде, допускающем независимый аудит и модификацию специально дрессированным специалистом dba. И схема данных, разработанная им же, и, скорее всего, имеющая довольно приблизительное отношение к классам и их реализации внутри вашего кода.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
19 сент. 2020, в 12:04
1000 руб./в час
19 сент. 2020, в 11:59
20000 руб./за проект
19 сент. 2020, в 11:26
17500 руб./за проект