Сколько таблиц/sprocs/функций в базе данных слишком много?

Question

Меня интересует рефакторинг базы данных. Я имею дело с несколькими базами данных, которые не имеют большого объема данных, всего несколько ГБ, содержащих не более нескольких сотен тысяч строк. Однако у них сотни, а иногда и сотни сотен - таблиц, представлений, sprocs и функций. В некоторых местах была реализована стратегия разделения и правила с использованием схем, которая помогла некоторым проблемам увидеть принадлежность/использование таблиц. Однако это не помогло объектной связи.

Мы все читали, что integration via shared database не является хорошей вещью, но мы также знаем, что это, по крайней мере, какое-то время, очень продуктивная вещь, поскольку все в базе данных. Мы просто не применяем Single Responsibility Principle к базам данных, как к объектам.

Редактировать: Я должен добавить, что у меня нет проблем с производительностью базы данных. Таблицы невелики, у самого большого есть всего несколько сотен тысяч строк. Нет реальной проблемы с производительностью базы данных; за исключением случаев, когда схема/логика/реализация базы данных гротескно неэффективна (например, требуется, чтобы курсор выполнял выполнение sproc для каждой строки в результирующем наборе для предварительной обработки данных для отчета). Прежде чем вы скажете, что я должен их изменить, в этом весь смысл: я не могу, потому что база данных больше не находится в состоянии, в котором можно оценить влияние изменений.

Очевидно, что в какой-то момент вы говорите «Хватит!» и делятся на несколько баз данных, связанных сообщениями, ETL, уровнями приложений и т. д.

Вопрос в том, сколько их слишком много? Каков абсолютный верхний предел количества sprocs/таблиц/функций, которые вы можете иметь, прежде чем сойти с ума?

Answer 1

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

Мне было бы интересно узнать, влияет ли вся эта работа на вашу работу? И если это не так, то зачем это менять? Если это не повлияет на производительность каким-то ужасным образом, ваши клиенты не будут видеть какую-либо выгоду от вашей работы, и тогда в чем смысл?

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

Answer 2

Во-первых, перестаньте думать о базах данных в объектно-ориентированных терминах. Принципы объектно-ориентированного программирования просто НЕ применяются к реляционным базам данных.

Общие базы данных - это очень хорошая вещь с точки зрения бизнеса. Несколько баз данных, которые хранят информацию, которая должна быть передана между ними, быстро становятся более сложными, чем ваши сотни разных объектов. Данные, совместимые между корпоративными приложениями, бесценны. Попытка примирить, если GE Corp и General Electric Corporation действительно являются одной и той же сущностью между двумя базами данных, могут стать кошмаром.

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

Часто лучший способ для рефакторинга - это добавить изменения и перейти к использованию нового поля, sp и т. Д., Оставив старый на месте до установленной даты истечения срока действия. Поскольку вы находитесь на ежегодном цикле, вам нужно будет управлять этими датами в течение длительного периода времени.Чтобы узнать, используются ли sps, вы можете определить те, на которые не уверены, и добавить к ним код для их вставки в таблицу при каждом запуске. Если после вашего круглогодичного цикла они не были запущены, вы можете безопасно их устранить. Цикл может быть короче в зависимости от sp.

Если я пишу что-то, что будет выполняться только ежегодно, я бы обычно помещал слово «годовое» в имя sp. Но, возможно, это не так, если вы находитесь, но функция sp должна дать вам представление, если это то, что должно выполняться только периодически. Я бы не ожидал, что usp_send email proc будет запускаться только один раз в год, но я мог бы ожидать, что файл usp_attendance_report может не запускаться часто. Конечно, как я сказал, я бы назвал это чем-то более похожим на usp_annual_attendance_report, и вы можете подумать о том, чтобы делать такие вещи, продвигаясь вперед.

Но имейте в виду, что любой рефакторинг, который вы делаете, должен проходить в течение длительного цикла, чтобы убедиться, что вы не удаляете что-то, что вам нужно. Если ваш код находится в исходной системе управления (и все таблицы базы данных, sp, views, UDF, триггеры и т. Д.), Вы, вероятно, можете устранить некоторые вещи, зная, что если они не удастся, вы сможете их мгновенно вернуть. Опять же, я бы исследовал объект, чтобы определить, какой риск может устранить их.

Конечно, если у вас есть хорошие автоматические тесты на месте, устранение чего-либо на dev и запуск тестов могут помочь вам узнать, есть ли что-то еще.

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

Хорошая книга по базам данных рефакторинга: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533