(трудный вопрос), как я могу хранить определенные строки таблицы на другом сервере SQL?

Question

У меня небольшая проблема с архитектурой. Скажем, у меня есть две таблицы: Учитель и Ученик , обе на разных серверах. Поскольку эти таблицы имеют много данных и функциональности, я хотел бы использовать эту схему наследования и создать таблицу People ; тем не менее, мне нужно будет хранить таблицу Учитель и записи People , относящиеся к Учитель , на одном сервере, а также таблицу Student и Люди Записи, касающиеся Ученик на другом сервере. Это было требование ведущего разработчика, поскольку у нас слишком много (и я имею в виду слишком много) записей для Teacher и Student , и одна база данных, содержащая всех людей, будет разрушаться. Более того, клиенты НУЖНЫ , чтобы иметь их на отдельных серверах (вздох *).

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

--- РЕДАКТИРОВАТЬ ---

Хорошо, у меня действительно нет Учителей и Студентов как таковых, я просто использовал эти имена, чтобы упростить свое объяснение. По правде говоря, существует около 9 вложенных таблиц, которые унаследовали бы супер таблицы, все они на отдельных серверах для отдельных приложений, и нет, у меня нет базы данных этого , но у нас есть довольно бюджетные серверы на количество транзакций у нас;). Вы правы, мои высказывания немного преувеличены, и я прошу прощения за это, просто чтобы вы, ребята, ответили быстрее (извините: P). Разные серверы являются скорее бизнес-ограничением, чем что-либо еще (хотя ведущий разработчик сказал, что общая база данных для хранения SuperTable рухнет под собственным весом - его словами, а не моими: S). Нашим клиентам не нравится, когда их информация смешивается с информацией других клиентов, поэтому мы должны размещать их информацию на разных серверах - довольно глупо, но лица, принимающие решения, говорили: (.

Answer 1

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

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

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

Answer 2

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

Что меня интересует, так это действительно ли это хорошее требование; В нем много технических сложностей, основанных на довольно простом утверждении, что данных слишком много. Вы пытались это проверить? Простым тестом будет создание простой схемы и заполнение ее фиктивными данными для числа строк, ожидаемых в рабочей среде. Вероятно, в ваших интересах выполнить этот тест, прежде чем идти слишком далеко, чтобы выполнить это «требование».

Кстати, тип схемы, к которой вы привязаны, является примером шаблона наследования таблиц классов .

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

Answer 3

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

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

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

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

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

РЕДАКТИРОВАТЬ: В ответ на те, кто задает вопрос, какое преимущество Oracle может дать в такой ситуации, можно было бы найти в области базы данных объединения, где она гораздо более зрелая. Другой может быть в таблицах, где у вас много разногласий, он делает копии данных в определенных ситуациях, и в целом его модель более сложна, когда речь идет об обработке разногласий. Например, сценарии, в которых таблицы читаются в более длительных запросах, что вызывает много потенциальных блокировок чтения. Oracle помогает вам поддерживать целостность транзакций, не блокируя чтение. В MS-SQL вам приходится прибегать к грязному чтению.

MS-SQL - прекрасная база данных, но у нее есть свои пределы (хотя необработанные объемы данных без каких-либо конкретных параметров, касающихся объема операций чтения и записи, на самом деле не являются одними из них, что делает вопрос странным). И, учитывая жесткую конкуренцию, версия Oracle для предприятий не является достаточно близкой по цене, чтобы ее стоило посмотреть. Это может стоить вам намного позже.

Конечно, если вы уже приобрели лицензию MS-SQL, коэффициент затрат для Oracle будет выше, поэтому преимущества должны быть более очевидными.

Answer 4

Какой клиент вы используете? Если вы используете клиент Java и используете ORM, возможно, вы захотите изучить Осколки гибернации .

Answer 5

свяжите серверы и создайте представление

SELECT
  FirstName
    ,LastName
    ....
  FROM server.database.owner.Teachers
UNION
  FirstName
    ,LastName
    ....
  FROM server.database.owner.Students

Answer 6

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

Answer 7

Слишком много записей вызывают «крах базы данных»? Что за горшок этот ведущий разработчик курит? Сильные вещи!

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

Answer 8

Я здесь с Аароном (выше Аарона). Переместить таблицы в одну базу данных. SQL Server может легко обрабатывать миллиарды строк на таблицу (я делал это на SQL 2000 6-7 лет назад, поэтому современные версии и современное оборудование не представляют проблем). До тех пор, пока ваши таблицы проиндексированы правильно. Вероятно, в каждой школе в мире не было достаточного количества учеников, чтобы перегружать SQL Server в одной школе.

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

Answer 9

Я думаю, что Пол прав - возможно, посмотрите на вашу аппаратную инфраструктуру, а не на схему БД.

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

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

например. Студенческий запрос

SELECT *
FROM SERVER_A.People.dbo.Persons P
    INNER JOIN SERVER_B.People.dbo.Students S
        ON P.PersonID = S.PersonID

- РЕДАКТИРОВАТЬ - Как сказал Пол, вы можете выполнить разделение базы данных на уровне абстракции.

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