Каковы преимущества/недостатки и рекомендации по использованию единой базы данных?

Ответ 1

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

Правильное использование файловых групп приведет к тому, что большая часть "минусов", приведенных в предыдущих ответах, исчезнет: они могут распространять ввод-вывод, они могут дезинфицировать ваши планы обслуживания и стратегию резервного копирования/восстановления, они предлагают доступность, поврежденная часть db в случае аварии. Поэтому я бы сказал, что, хотя эти "минусы" являются законными проблемами, их можно смягчить с помощью надлежащей стратегии развертывания. Это правда, хотя эти действия по смягчению требуют истинного, опытного dba у руля, поскольку они выйдут за пределы зоны комфорта разработчика, превратившегося dba по необходимости.

Некоторые из профессионалов, о которых я могу думать быстро:

• Последовательность. Вы можете восстановить резервную копию, чтобы все данные были согласованными. Отдельные dbs не позволяют этого, потому что вы не можете координировать согласованный набор резервных копий, если вы не отключите их в автономном режиме или не сделаете их r/o во время резервного копирования.
• Дешевая высокая доступность грязи: вы можете развернуть зеркальное отображение базы данных для восстановления работоспособности и высокой доступности. У нескольких баз данных есть проблемы, потому что невозможно согласовать одновременный переход на другой ресурс, и приложения сталкиваются с дилеммой поиска каждого текущего местоположения базы данных.
• Безопасность. В то время как большинство других сообщений видят, что одна база данных сложнее защитить, я бы сказал, проще. Множественные базы данных кажутся более сложными для обеспечения безопасности, потому что все, что они делают, это сделать один вход и добавить его в эту базу данных db_owner. Наличие одной базы данных сделает все сложнее (если только вы не создадите всех dbo, очень плохо), но как только вы начнете делать правильные вещи (гранулированный доступ), тогда один db не сложнее, чем несколько dbs, на самом деле проще, потому что у вас не будет копировать/поддерживать некоторые общие группы/права в нескольких dbs.
• Control. Будет проще навязать определенные политики и передовые методы работы на одном db, а не на нескольких (доступ к данным для разработчиков, доступ к данным приложений не будет возможен только через выполнение прав на схему для обеспечения доступа к процедурам и т.д.).

Есть и некоторые недостатки, которые я не видел в других сообщениях:

• Это будет намного сложнее снять, что вы думаете прямо сейчас.
• Увеличение связи между ранее разделенными приложениями приведет к ограничениям на разработку: вы не можете просто изменить свою схему, вам придется координировать ее с остальными приложениями (вы можете утверждать, что это было так и раньше, но было очищено под ковром, имея отдельные dbs, и вы правы)
• Журнальные записи, которые теперь распределены между несколькими журналами db, будут объединены в один файл журнала. Если ваши записи значительны, это может оказаться серьезным узким местом и заставить вас купить дорогие быстрые диски для нового консолидированного файла журнала. В общем случае это могут быть адреса, делая лог-диск разделенным массивом на столько полосок, сколько необходимо, чтобы сделать его достаточно быстрым (обычно рейд 10).
• GAM/SGAM/PFS будут также консолидированы, но опять же это будет смягчено путем правильного использования групп файлов.

Ответ 2

Плюсы:

• Вам нужно только запомнить одну строку подключения
• Когда пользователи сообщают, что доступ медленный, вы знаете, какая из БД вызывает проблемы.

Минусы:

• Резервное копирование One DB займет много времени и со временем будет становиться более продолжительным.
• Восстановление данных из резервной копии будет усложняться.
• Настройка производительности (SQL Profiler, оценка плана выполнения) для функции для одного приложения замедлит каждое приложение.
• Ограничение доступа к данным одного приложения громоздко, если это вообще возможно, что, вероятно, на практике означает, что всем разработчикам и администраторам баз данных будут предоставлены ключи от ENTIRE kingdom.
• Новые разработчики/администраторы баз данных имеют гораздо более широкую кривую обучения, поскольку им необходимо ориентироваться в большой и в большинстве своем бесполезной структуре базы данных, что означает более высокие затраты на обучение/наращивание.
• Когда база данных One падает, все в вашей организации играют пасьянс, пока не будут восстановлены.
• Создание тестовых экземпляров для разработки приложений означает копирование всего db

Ответ 3

Единственный "Pro", о котором я могу думать, заключается в том, что все ваши системы будут в одной базе данных и, следовательно, в одном месте для резервного копирования, хранения и т.д. Однако я считаю это также одним из самых больших "Против".

Некоторые другие общие недостатки:

• Намного сложнее переместить приложение в другое место/сервер в будущем.
• Возможные проблемы с блокировкой, если какие-либо приложения используют tempdb.
• Возможная несвязанная деградация производительности в одном приложении, когда используется другое приложение.
• Намного сложнее реализовать модель безопасности уровня приложения, если все таблицы находятся в одной базе данных.

Ответ 4

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

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

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

Здесь вам действительно нужна ваша компания: иметь одну единственную базу данных CONCEPTUAL, содержащую все "данные предприятия" и определяемую таким образом, чтобы соблюдались как ссылочная целостность, так и целостность объекта. Пересмотрите существующие схемы, чтобы они соответствовали базе данных CONCEPTUAL, за исключением данных, которые являются чисто локальными для этой схемы и недокументированы в единой концептуальной базе данных. Используйте ограничения везде, где это необходимо, чтобы гарантировать, что данные, охватываемые этими схемами, не потеряют целостность.

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

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

Документируйте концептуальную базу данных из gazoo. Не просто соглашайтесь на определения ФОРМЫ данных. Настаивайте на определениях семантики данных.

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

Это не будет легко.

Ответ 5

Если БД становится все больше, создание резервной копии становится более сложным из-за его размера.

Ответ 6

Это может означать серьезную проблему масштабируемости, если вы хотите добавить приложения с большим трафиком в будущем, так как гораздо проще добавить новые серверы баз данных, которые запускают отдельные dbs, чем для параболизации одного БД. По крайней мере, в SQL Server.

Ответ 7

Плюсы:

• Удобство всего в одном месте
• Мысль о хорошем дизайне базы данных меньше

Минусы:

• Даже несвязанные вещи находятся в одном месте.
• Меньше думать о хорошем дизайне базы данных, приводящем к плохо нормализованным данным.

Для меня это просто звучит как лень и вера в то, что вся эта "фантастическая база данных башенки из слоновой кости" бесполезна.

Ответ 8

Я вижу, что это страшно, но учитывая количество компаний, использующих Oracle EBS или SAP, или другие системы, которые по сути являются той же конфигурацией, я не вижу, что это Bad Thing & trade;. Это большой шаг, и будет сложно получить правильное решение, но оно может действительно улучшить интеграцию на предприятии в долгосрочной перспективе.

Ответ 9

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

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

Ответ 10

А, старый шаблон дизайна EggsInOneBasket. Это не фаворит.

Вы просто усугубляете любые проблемы, вызванные повреждением этой базы данных. Распространяйте риск!

Ответ 11

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

На том же сервере вы можете либо нажимать, либо извлекать данные из официального репозитория основных данных и вставлять любые новые строки/обновлять любые измененные строки. Вы даже можете сделать это с помощью триггера в основной базе данных (я не рекомендую это делать).

Если это разные экземпляры или серверы, вы можете использовать связанные серверы или SSIS.

Вы можете поместить общие данные в "основную" схему в каждой базе данных. Затем вы можете иметь инструменты для проверки того, что все ваши основные таблицы в каждой дочерней базе данных согласованы. Хуже того, что может случиться, что приложение не видит нового сотрудника, потому что ядро ​​не обновляется. И сохранение вашей базы данных в отдельности дает вам возможность отделить и предоставить вам окна обслуживания. (Вы даже можете отделить и запустить "автономный", если ваш мастер не работает для обслуживания).

Я ожидаю, что вы увидите лишь несколько десятков этих основных таблиц сущностей даже в довольно крупном предприятии.

Ответ 12

Существует множество других способов решения проблемы ссылочной целостности (RI). Я не так хорошо знаком с SQL Server, как с другими БД. В Informix вы можете использовать синонимы для указания объектов в другой БД и использовать их для своего RI. В Oracle вы можете сделать связь БД с одной или несколькими БД, чтобы выполнить одно и то же. Эти подходы имеют проблему: если какая-либо из БД не работает, RI не будет вызывать проблемы в зависимых БД. выбор будет работать, но вставки не удастся. Консолидация может быть хорошей идеей, в зависимости от размера схемы и других проблем с масштабируемостью. SQL Server имеет серьезные проблемы с масштабируемостью. Другие платформы БД позволяют горизонтальное масштабирование либо с общим подходом (Oracle RAC, либо с последней версией Informix), либо с разделяемым общим доступом (DB2 DPF, Informix XPS, Netezza, Teradata)

Я с некоторыми из других заинтересованных здесь, чтобы услышать результаты вашей встречи.