Несколько баз данных против одной базы данных
Я смотрю на существующий сайт, и они используют отдельные базы данных. Кажется, что базы данных настроены следующим образом:
- общие типы (user_type, язык, возраст и т. д.)
- данные участника (регистрационная информация и логин)
- конфигурация сайта
Лично я бы все поместил в 1 базу данных. Для меня это было бы проще, чем почти всегда указывать имя базы данных перед каждой таблицей.
Я могу видеть с точки зрения безопасности, что люди не могут случайно получить доступ к неправильным данным, но на этом сайте будут администраторы (около 10% пользователей сайта), которым потребуется доступ ко всем базам данных, выполняя перекрестные поиск в базе данных.
В чем могут быть причины для создания отдельных баз данных? (Сайт находится на PHP и MySQL.)
Редактировать: Имена базы данных:
sitename(фактическое название сайта) (общие типы)member(членские данные)siteconfig(конфигурация сайта)
Ответы 5
Чисто предположение о том, что было в головах создателей:
Может быть, разница в volitilaty данных, чтобы могла быть другая стратегия резервного копирования / репликации для разных физических dbs?
Может быть, идея о том, что «общие типы» могут быть общими для нескольких приложений, но, например, «конфигурация сайта» будет специфичной только для одного приложения?
Возможно, возникла идея о том, что разные базы данных могут быть размещены на разных аппаратных средствах, которые имеют разные характеристики производительности, например конфигурацию RAID. Данные, которые много читаются, но не обновляются, по сравнению с данными, которые часто обновляются.
Опять чистое предположение ...
@Darryl - мой ответ больше археология, чем технология. Я не говорю, что покупаю что-либо из этого. Я просто пытаюсь проникнуть в образ мышления предков ...
99% археологии просеивают груды дерьма, которые оставляют после себя люди, так что ваша аналогия превосходна.
Здесь! Какое хорошее имя / титул для тех, кому приходится поддерживать программное обеспечение (особенно плохо документированное): Археолог программного обеспечения! Мне это нравится! И ответ мне, конечно, нравится!
@ Кори Трейджер: Хорошая идея, но вы, конечно, можете указать, какие таблицы следует резервировать, а также, насколько будет отличаться выбор только из некоторых при постоянном обновлении других таблиц?
Также чистое предположение: возможно, это было архитектурное решение для поддержки разделения интересов.
Не разбираюсь в термонологии ... Вы можете объяснить опасения?
Поправьте меня, если я ошибаюсь, но в целом это означает, что вы разделяете дизайн и работу и передаете их другому разработчику, чтобы найти лучшее решение этой проблемы, а не общее решение для всего.
Я не могу придумать причину для создания нескольких баз данных для указанной вами информации, особенно если эти данные должны быть связаны между собой. Похоже, что кто-то не знал, как использовать разрешения, поэтому вместо предоставления доступа к таблицам они просто создали новые базы данных. Просто мнение, но сокращение всего до одной базы данных, вероятно, было бы улучшением.
Удивительно, что может произвести невежество. Я работаю с базой данных, у которой вообще нет первичных ключей, и эта ситуация возникла из-за того, что первоначальные разработчики не знали, как создавать представления.
@MusiGenesis Я пропустил это. :( Какая связь между отсутствием первичных ключей и созданием представлений?
Если бы существовала веская причина для разделения базы данных на кучу таких более мелких, как эта, базы данных, вероятно, имели бы имена вроде «hadronsupercolliderrawdata» и «googlebackup_2008». Такие имена, как «общие типы» и «членские данные» предполагают, что их просто поразила глупость.
есть ли причина, по которой вы чувствуете необходимость оскорбить чей-то интеллект на основании дизайна его приложения? Возможно, они были (и скорее всего) начинающими программистами в начале проекта / компании. Сказать, что кто-то «глуп» из-за плохого дизайна, заставляет вас так выглядеть.
@ JM4: говорить, что я глупый, потому что я назвал глупым кого-то еще, - это что-то вроде, ну, глупо, если ты не против, что я так говорю. Сказать, что я придурок, потому что я назвал кого-то глупым, было бы совершенно правильно, а также не глупо. Что касается сути вашего комментария, конечно, они были начинающими программистами в начале проекта - именно отсюда происходит большая часть плохого кода.
@MusiGenesis Я действительно многому научился из этого обмена, хотя я бы заменил глупость на «невежество».
Да, это безумие низкого уровня. Больше работы для программистов, но отдача - больше работы для программистов.