Каковы профессионалы/недостатки и лучшие практики для использования единой базы данных?
Для этого теперь есть новое свойство css3: text-decor-color
Теперь вы можете иметь текст в одном цвете и подчеркивание текста в другом цвете. .. без необходимости дополнительного элемента «обтекания»
p {
text-decoration: underline;
-webkit-text-decoration-color: red; /* safari still uses vendor prefix */
text-decoration-color: red;
}black text with red underline in one element - no wrapper elements here!
Codepen
Примечание:
1) Поддержка браузеров на данный момент ограничена Firefox и Chrome (полностью поддерживается с V57) и Safari
] 2) Вы также можете использовать сокращенное свойство text-украшение , которое выглядит следующим образом:
|| ||
... так что используйте сокращение text-decoration - приведенный выше пример будет просто :
p {
text-decoration: underline red;
}
p {
text-decoration: underline red;
}black text with red underline in one element - no wrapper elements here!
12 ответов
Большую базу данных труднее обслуживать из-за огромного размера: резервное копирование занимает больше времени, аварийное восстановление происходит медленнее, что, в свою очередь, требует более частого резервного копирования. Вы можете решить эти проблемы, создав файловые группы и используя резервное копирование на уровне файловых групп в планах обслуживания, а при аварийном восстановлении вы можете использовать стратегию « частичное восстановление », чтобы ускорить процесс.
Правильно. использование файловых групп устранит большинство недостатков, упомянутых в предыдущих ответах: они могут распределять ввод-вывод, они могут очищать ваши планы обслуживания и стратегию резервного копирования / восстановления, они обеспечивают доступность, переводя в автономный режим только поврежденную часть БД в случае сбоя. Поэтому я бы сказал, что, хотя эти «минусы» являются законными проблемами, они могут быть смягчены правильной стратегией развертывания. Это правда, что эти действия по смягчению последствий требуют истинного, опытного, DBA у руля, поскольку они выйдут за пределы зоны комфорта разработчика, который превратился в DBA по необходимости.
Некоторые из плюсов, о которых я могу быстро вспомнить:
- Последовательность . У вас может быть резервное копирование-восстановление, чтобы все данные были согласованы. Отдельные базы данных не позволяют этого, потому что вы не можете координировать согласованный набор резервных копий, если не отключите их все или не отключите их во время резервного копирования.
- Низкая доступность: вы можете развернуть зеркальное отображение базы данных для восстановления после сбоев и высокой доступности. У нескольких баз данных есть проблемы, потому что невозможно координировать одновременное переключение на другой ресурс, и приложения сталкиваются с дилеммой поиска каждой базы данных текущего местоположения.
- Безопасность. В то время как большинство других сообщений видят, что одну базу данных труднее защитить, я скажем, проще защитить. Кажется, что несколько баз данных сложнее защитить должным образом просто потому, что все делают один логин и добавляют его в эту группу db_owner базы данных. Наличие одной базы данных усложнит задачу (если вы не сделаете все dbo, очень плохо), но как только вы начнете делать правильные вещи (детальный доступ), тогда один db не сложнее, чем несколько dbs, на самом деле проще, потому что у вас не будет для копирования / поддержки некоторых общих групп / прав в нескольких базах данных.
- Control. Будет легче навязать определенные политики и передовые методы одной базе данных, чем нескольким (отсутствие доступа к данным для разработчиков, доступ к данным приложения только через права выполнения в схеме для обеспечения доступа к процедурам и т. Д.).
Есть также некоторые недостатки Я не видел в других постах:
- Это будет намного сложнее, чем вы думаете сейчас.
- Увеличение связи между ранее разделенными приложениями наложит ограничения на разработку: вы не можете просто изменить свою схему, вам придется согласовывать ее с остальной частью приложений (вы можете возразить, что так было и раньше, но это было скрыто за счет наличия отдельных баз данных, и вы правы)
- Записи журналов, которые теперь распределены по нескольким журналам баз данных, будут объединены в один единственный журнал файл. Если ваши записи значительны, это может оказаться серьезным узким местом и вынудить вас купить дорогие быстрые диски для нового консолидированного файла журнала. В общем, это можно решить, сделав дисковый журнал разделенным на столько полос, сколько необходимо, чтобы сделать его достаточно быстрым (обычно рейд 10).
- Распределения GAM / SGAM / PFS также будут объединены, но опять же, это будет облегчено правильным использованием групп файлов.
Плюсы:
- Вам нужно запомнить только одну строку подключения
- Когда пользователи сообщают о медленном доступе, вы знаете, какая БД вызывает проблемы
Минусы:
- Резервное копирование The One DB займет много времени и будет становиться все дольше со временем.
- Восстановление данных из резервной копии будет становиться все труднее.
- Настройка производительности (SQL Profiler, оценка плана выполнения) для функции для одного приложения замедлит работу каждого приложения.
- Ограничение доступа к данным отдельного приложения является обременительным, если это вообще возможно, что на практике, вероятно, будет означать, что всем разработчикам и администраторам баз данных будут предоставлены ключи от ВСЕГО царства.
- Новым разработчикам / администраторам баз данных требуется гораздо больше времени на обучение, поскольку им необходимо ориентироваться в большой и в основном бесполезной (для них) структуре базы данных, что означает более высокие затраты на обучение / наращивание мощности.
- Когда база данных The One выходит из строя, все в вашей организации играют в пасьянс, пока она не будет восстановлена.
- Создание тестовых экземпляров для разработки приложений означает копирование всей вашей базы данных
Если база данных становится больше, резервное копирование становится все труднее из-за ее размера.
Единственное «профи», о котором я могу думать, это то, что все ваши системы будут в одной базе данных и, следовательно, в одном месте для резервного копирования, хранения и т. Д. Однако я бы посчитал это также является одним из самых больших "минусов".
Некоторые другие общие минусы:
- Намного труднее переместить приложение в другое место / сервер в будущем.
- Возможные проблемы с блокировкой, если какое-либо приложение использует tempdb .
- Возможное несвязанное снижение производительности одного приложения при использовании другого приложения.
- Намного сложнее реализовать модель безопасности на уровне приложения, если все таблицы находятся в одной базе данных.
Я вижу, что это пугает, но, учитывая количество предприятий, использующих Oracle EBS, SAP или другие системы, которые, по сути, имеют такую же конфигурацию, я этого не вижу. быть Bad Thing ™. Это большой шаг, и его будет сложно исправить, но он действительно может улучшить интеграцию в масштабе предприятия в долгосрочной перспективе.
Это может означать серьезную проблему масштабируемости, если вы хотите добавить приложения с высоким трафиком в будущем, поскольку гораздо проще добавить новые серверы баз данных, которые запускают отдельные базы данных, чем распараллеливать единая БД. По крайней мере, в SQL Server.
Плюсы:
- Удобство, когда все в одном месте
- Меньше думать о хорошем дизайне базы данных
Минусы:
- Даже несвязанные вещи находятся в одном месте
- Меньше размышлений о хорошем дизайне базы данных, приводящем к плохо нормализованным данным
Для меня это звучит как лень и вера в то, что вся эта «модная база данных о башне из слоновой кости» бесполезна.
Я никогда не слышал об этом подходе и хотел бы знать, как проходит встреча. Я не вижу реальной выгоды в объединении нескольких приложений в единую базу данных, когда данные не связаны друг с другом.
Я думаю, у вас могут возникнуть проблемы, если вы решите, что приложению требуется собственный сервер базы данных в какой-то момент.
Ах, старый шаблон проектирования EggsInOneBasket. Это не фаворит.
Вы просто усугубляете проблемы, вызванные повреждением этой базы данных. Распространяйте риск!
Есть много других способов решить проблему ссылочной целостности (RI). Я не так хорошо знаком с SQL Server, как с другими БД. В Informix вы можете использовать синонимы, чтобы указывать на объекты в других базах данных и использовать их для своего RI. В Oracle вы можете сделать связи БД с одной или несколькими БД, чтобы выполнить то же самое. У этих подходов есть проблема, заключающаяся в том, что если какая-либо из БД не работает, RI не сможет вызвать проблемы в зависимых БД. select будет работать, но вставка не удастся. Консолидация может быть хорошей идеей, в зависимости от размера схемы и других проблем с масштабируемостью. SQL Server имеет серьезные проблемы с масштабируемостью. Другие платформы БД допускают горизонтальное масштабирование либо с использованием подхода общего доступа (Oracle RAC, последняя версия Informix), либо подхода с разделением без общего доступа (DB2 DPF, Informix XPS, Netezza, Teradata)
. Я вместе с некоторыми другими здесь заинтересованными услышать результаты вашей встречи.
Мне кажется, что ваша компания переходит между двумя совершенно разными мотивами использования технологии баз данных. Первый - это поддержка приложений. Второй - интеграция данных. Если я прав насчет этого, процесс откроет огромную банку червей, и многие проблемы даже не будут решены путем помещения всех данных в одну большую базу данных.
Обдумайте два из сделанных вами замечаний. . Первая - это полное отсутствие ссылочной целостности в разных базах данных. Во-вторых, у каждого приложения будет своя собственная схема. Это приводит к полному отсутствию ссылочной целостности во всех схемах, возвращая вас в зыбучие пески, в которых вы находитесь сейчас.
Исправление данных так, чтобы ссылочная целостность присутствовала, и исправление схем, чтобы ссылочная целостность была обеспечена, и исправление приложений таким образом, чтобы приложения соответствовали новым схемам, окажется монументальной задачей.
Вот что действительно нужно сделать вашей компании: иметь одну единую КОНЦЕПТУАЛЬНУЮ базу данных, содержащую все "корпоративные данные" и определенную в таким образом, что обеспечивается как ссылочная целостность, так и целостность объекта. Внесите изменения в существующие схемы, чтобы они соответствовали КОНЦЕПТУАЛЬНОЙ базе данных, за исключением данных, которые являются как чисто локальными для этой схемы, так и недокументированными в единой концептуальной базе данных. Используйте ограничения везде, где это необходимо, чтобы гарантировать, что данные, охватываемые этими схемами, не потеряют целостность.
Примите решение о том, принадлежат ли эти схемы одной базе данных или нескольким базам данных, на основе администрирования базы данных, обеспечения отказоустойчивости, требований безопасности и производительности, а НЕ на необходимости интеграции данных. Независимо от того, используете ли вы одну платформу или несколько платформ - это отдельное решение.
При необходимости поддерживайте синхронизированные копии одних и тех же данных в отдельных базах данных. Включите накладные расходы, связанные с этим, в свои соображения по производительности выше.
Документируйте концептуальную базу данных из газу. Не соглашайтесь только на определения ФОРМЫ данных. Также настаивайте на определении семантики данных.
Обратите внимание, что если вы используете поля идентификатора вместо естественных ключей для обеспечения ссылочной целостности, вам придется сгенерировать каждое поле идентификатора в одной схеме и позволить ассоциации между идентификатором и зависимыми данными распространяться с помощью синонимов, представлений и синхронизации. репликация.
Это будет непросто.
поддерживать синхронизированные копии одних и тех же данных в отдельных базах данных. Включите накладные расходы, связанные с этим, в свои соображения по производительности выше.Документируйте концептуальную базу данных из газу. Не соглашайтесь только на определения ФОРМЫ данных. Также настаивайте на определении семантики данных.
Обратите внимание, что если вы используете поля идентификатора вместо естественных ключей для обеспечения ссылочной целостности, вам придется сгенерировать каждое поле идентификатора в одной схеме и позволить ассоциации между идентификатором и зависимыми данными распространяться посредством синонимов, представлений и синхронизации. репликация.
Это будет непросто.
поддерживать синхронизированные копии одних и тех же данных в отдельных базах данных. Включите накладные расходы, связанные с этим, в свои соображения по производительности выше.Документируйте концептуальную базу данных из газу. Не соглашайтесь только на определения ФОРМЫ данных. Также настаивайте на определении семантики данных.
Обратите внимание, что если вы используете поля идентификатора вместо естественных ключей для обеспечения ссылочной целостности, вам придется сгенерировать каждое поле идентификатора в одной схеме и позволить ассоциации между идентификатором и зависимыми данными распространяться посредством синонимов, представлений и синхронизации. репликация.
Это будет непросто.
Я просто соглашусь на определения ФОРМЫ данных. Также настаивайте на определении семантики данных.Обратите внимание, что если вы используете поля идентификатора вместо естественных ключей для обеспечения ссылочной целостности, вам придется сгенерировать каждое поле идентификатора в одной схеме и позволить ассоциации между идентификатором и зависимыми данными распространяться посредством синонимов, представлений и синхронизации. репликация.
Это будет непросто.
Я просто соглашусь на определения ФОРМЫ данных. Также настаивайте на определении семантики данных.Обратите внимание, что если вы используете поля идентификатора вместо естественных ключей для обеспечения ссылочной целостности, вам придется сгенерировать каждое поле идентификатора в одной схеме и позволить ассоциации между идентификатором и зависимыми данными распространяться посредством синонимов, представлений и синхронизации. репликация.
Это будет непросто.
Что касается проблемы ссылочной целостности, вы можете сделать копии этих общих таблиц во вспомогательных базах данных. Вы не можете использовать реальную репликацию, но то, что вы делаете, это отрицаете все, но выбираете это для большинства пользователей.
На том же сервере вы можете либо отправить, либо получить данные из официального репозитория основных данных и вставить любые новые rows / обновить любые измененные строки. Вы даже можете сделать это с помощью триггера в базе данных master (хотя я не рекомендую это делать).
Если это разные экземпляры или серверы, вы можете использовать связанные серверы или SSIS.
Вы можете поместить общие данные в схему «ядра» в каждой базе данных. Затем у вас могут быть инструменты для проверки согласованности всех ваших основных таблиц в каждой вспомогательной базе данных. Хуже того, что приложение не видит нового сотрудника, потому что ядро не обновлено. А хранение вашей базы данных отдельно дает вам возможность разделить и дает вам окна обслуживания. (Вы даже можете разделить и запустить "автономно", если ваш главный компьютер отключен для обслуживания.)
Я ожидаю, что вы увидите только несколько десятков этих основных таблиц сущностей даже на большом предприятии.