Ответы пользователя по тегу SQL Server
  • На каких объемах данных реляционные БД перестают работать?

    Zorkus
    @Zorkus
    Вообще я бы сказал, если не говорить о ценах, а просто об объемах данных, вы еще далеко от того предела, когда реляционные базы не будут выдерживать вашей нагрузке, если конечно ваша модель данных именно реляционая. В полной стойке Exadata V2-8, например, почти 5 терабайт только Flash Cache Memory (и 100/330 теребайт основного хранилища, смотря по тому, поставите вы SCSI или SATA для него.)
    Ответ написан
    Комментировать
  • На каких объемах данных реляционные БД перестают работать?

    Zorkus
    @Zorkus
    Ну вообще говоря, 2.7 Тб само по себе не так много (телекомы используют гораздо большего объема базы). Мы использовали базы около 3 терабайт на оракле, сначала два обычных среднего уровня сервера в RAC, потом пробовали Exadata DB Machine Quarter Rack (http://www.oracle.com/us/products/database/exadata-database-machine/overview/index.html — прочитайте, зверь-машина), все нормально работала.

    Ключевые проблемы:

    — partitioning и разделение это таблицы на отдельные секции, которые лежат на разных жестких дисках в рейде (критичные партиции, где лежат наиоболее горячие данные, можно положить на SSD)
    — будет ли идти большое количество «живых» запросов агрегирующих данных на высоком уровне? Запросы к таблице в несколько миллиардов записей выполняются вполне быстро, если они строго идут по partition keys, если таблица грамотно разбита на партиции, и если они лежат на разных дисках. Запросы типа — посчитать мне среднюю цену по 5 миллиардам заказов, конечно, вас быстро положат на лопатки, просто из-за сумасшедшего IO.
    — Диски. Оцените стоимость нормального SAN, посмотрите какие в MS SQL есть средства типа оракловского ASM (automatic storage manager).
    Ответ написан
    Комментировать
  • MS SQL Server. T-SQL. Организация "истории изменений"

    Zorkus
    @Zorkus
    По первой части вопроса могу сказать — да, дизайн вполне нормальный. Я использую примерно такой же подход (СУБД Oracle).

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

    Добавьте колонку last_modified_by_user на таблицу mytable, и, соответственно, таблицу mytable_history.
    Соответственно, когда какой-то пользователь выполняет операцию (insert / update / delete), вы выставляете ID-шник этого юзера, и при срабатывании вашего after-insert, after-update, after-delete row-level триггера этот айдишник перенесется в таблицу аудита.

    А как вставлять айдишник пользователя изначально в таблицу mytable? Ну, создавать server-side user-context в котором хранится имя-id пользователя, ассоциированный с пользовательской сессий, и при выполнении запроса с уровня бизнес логики — заполнять это поле.

    Как-то так.
    Ответ написан