Должны ли статические данные базы данных находиться в отдельной файловой группе?

Я создаю новую БД и имею кучу статических данных, которые не изменятся. Если это произойдет, это будет ручной процесс И это будет происходить очень редко.

Эти данные представляют собой смесь varchars и Geographies.

Я предполагаю, что это может быть около 100 тысяч или около того, более 4 столов или около того.

Вопросы

  1. Должен ли я поместить их в файловую группу ТОЛЬКО ДЛЯ ЧТЕНИЯ
  2. Могу ли я создать таблицы в дизайнере и определить файловую группу во время создания? Или это возможно только через скрипт?
  3. Как только данные будут в таблице (в файловой группе только для чтения), могу ли я изменить их позже? Неужели это сложно сделать?

благодаря.


sql-server sql-server-2008 database-design physical-design filegroup
person Pure.Krome    schedule 14.04.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Это того стоит для VLDB (очень больших баз данных) по разным причинам. Для 100 000 строк или 100 КБ я бы не стал заморачиваться.

Эта группа инженеров поддержки SQL Server в статье обсуждается одна из связанных с ней «городских легенд».

Есть еще один (не могу его найти), где вам нужно 300 ГБ - 1 байт данных, прежде чем вы должны рассмотреть несколько файлов / файловых групп.

Но конкретно отвечать

  1. Личный выбор (жестких правил нет)
  2. Да (редактировать:) В SSMS 2005, в режиме разработки, перейдите в раздел «Индексы/ключ», «спецификация пространства данных». Данные живут там, где находится кластеризованный индекс. Без кластерного индекса это можно сделать только через CREATE TABLE (..) ON filegroup
  3. Да, но вам придется ALTER DATABASE myDB MODIFY FILEGROUP foo READ_WRITE работать с базой данных в однопользовательском монопольном режиме.
person gbn    schedule 14.04.2009
comment
РЕ: вопрос №2. как определить файловую группу в дизайнере при создании таблицы? - person Pure.Krome; 14.04.2009

arrow_upward
1
arrow_downward

Вряд ли повредит помещать данные в пространство только для чтения, но я не уверен, что вы значительно выиграете. Файловая группа только для чтения (или табличное пространство в Oracle) может дать вам 2 преимущества; меньше резервного копирования каждый раз, когда создается полная резервная копия, и более высокий уровень безопасности данных (например, они не могут быть изменены ошибкой, доступом к БД с помощью другого инструмента и т. д.). Преимущество резервного копирования наиболее актуально для больших баз данных, где окна резервного копирования ограничены, поэтому полезно приложить небольшие усилия для исключения групп файлов. Безопасность зависит от характера сайта, данных и т. д. (если вы исключаете пространство только для чтения из обычных резервных копий, убедитесь, что вы получаете копию на всех сохраненных резервных лентах. Я обычно делаю резервные копии пространств только для чтения один раз месяц.)

Я не знаком с конструктором.

Переход на режим только для чтения и обратно не является обременительным.

person Karl    schedule 14.04.2009

arrow_upward
1
arrow_downward

Я думаю, что все, что вы здесь прочтете, скорее всего, будет спекуляцией, если только у вас нет доказательств того, что это действительно было опробовано и рекомендовано — мне это кажется новой, но маловероятной идеей. Есть ли у вас основания подозревать, что традиционная практика будет неудовлетворительной? Должно быть довольно легко просто попробовать и узнать. Опубликуйте свои результаты, если у вас есть шанс.

person dkretz    schedule 14.04.2009