Как поддерживать / генерировать таблицы в Hibernate для многопользовательских целей?

Question

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

team1_tablename team1_secondtable ..

Затем, когда определенный запрос достигает виртуального хоста (ex http://teamawesome.workshop.com) Мне нужно было бы выполнить запрос к определенной таблице.

Проблема не в создании таблиц, а в работе с моделями. Все мастерские будут иметь одинаковые общие таблицы.В модели мне нужно было бы указать таблицу и т. Д., Но тогда, если бы это был PHP с доктриной, я бы создал шаблон после создания мастерской team1, но в java, даже если я сгенерирую их, мне придется их тоже скомпилировать, чтотребует, чтобы я провел больше исследований.

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

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

Если есть какие-либо сомнения, дайте мне знать, спасибо (обратите внимание, что это не вопрос нескольких баз данных, просто использование разных наборов таблиц с уникальными префиксами)

Answer 1

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

Написал PlayPlugin и убедитесь, что вы добавляете к каждому запросу команду к запросу args.Тогда вы написали свой собственный NamingStrategy.В NamingStrategy вы можете прочитать request.args и поместить команду в название вашей таблицы.В зависимости от того, как вы его добавите Команда _ или Команда .это будет ваше предпочтительное решение или что-то со схемой.Похоже, у вас есть db-схема, так что, вероятно, было бы лучшим решением остаться с этими таблицами и не мигрировать.

Пожалуйста, сделайте в следующий раз ваш запрос более абстрактным, чтобы вы могли предоставить некоторую информациюнапример, сколько таблиц, является ли команда сущностью и сколько записей в таблице (max, avg, min).Насколько стабильна модель вашего стола?Это все вопросы, которые помогают дать четкую рекомендацию с аргументами.

Answer 2

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

Как упоминалось в других ответах (Quaternion's и Octav's), я думаю, что у вас есть два жизнеспособных варианта:

1. Внесите "команду" в вашу модель данных
2. Разделите данные в разных базах данных/ schemas

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

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

Расщепление жизнеспособно только в том случае, если:

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

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

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

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

Answer 3

Интересно, можете ли вы использовать один единственный набор таблиц, но иметь в качестве внешнего ключа что-то вроде TEAM_ID в каждой таблице.

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

Например, если у вас есть сущность Player, имеющая коллекцию HighScores, то в БД таблица Player будет иметь TEAM_ID (внешний ключ оттаблица Team) и таблица HighScores будут иметь составной внешний ключ (Player_id, Team_id), полученный из таблицы Player.

Итак, в заключение, я предлагаю логическое разбиение вашей базы данных,затем физический (как вы рассматривали изначально).

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

Answer 4

Я знаком с Hibernate и другим веб-фреймворком, вот как бы я справился с этим:

Я бы создал один набор таблиц для одной команды, который отвечал бы всем моим потребностям. Тогда я бы:

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

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

Теперь вы можете настроить отдельный файл hibernate.cfg.xml для каждого соединения (это не совсем лучший способ, но, возможно, лучше всего начать, потому что это так просто). Теперь вы можете указать параметры подключения ... включая схему / дБ. Теперь ваша таблица сущностей, скажем, называется "команда", будет использовать таблицу "команда", где бы она ни была подключена ...

Чтобы начать работу очень быстро, когда пользователь входит в систему, создайте объект пользователя в своем сеансе. У объекта пользователя будет Hibernate SessionFactory, который будет использоваться для всех запросов к базе данных, созданных из правильного файла hibernate.cfg.xml, что определяется путем анализа URL-адреса, используемого при входе в систему.

Как только вышеприведенное сработает ... Существуют серьезные проблемы с эффективностью, которые необходимо решить. Это потому, что каждый вошедший в систему пользователь создает SessionFactory ... Может быть, это не проблема, если не много одновременного использования, но вы, вероятно, захотите взглянуть на Spring и использовать пул соединений на группу. Таким образом, существует одна фабрика сессий для каждой команды, и нет создания основных объектов при входе пользователя.

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

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

Answer 5

Вы можете попробовать модуль vhost, но, похоже, он не очень хорошо поддерживается. Но я думаю, что идея поместить название команды в название таблицы действительно устарела. У Postgres и Oracle есть схемы для этого. Таким образом, вы используете myTeam.myTable. Но тогда вы должны сделать упорство самими собой. Другим подходом были бы другие базы данных, но опять же, у вас нет хорошей поддержки игрой. Я бы попробовал это

• Запустите для каждой команды отдельный игровой сервер, если вам не нужно много команд.
• Поставьте ссылку на Team-table для каждой модели. Затем вы можете использовать hibernate-фильтры или добавить его вручную в качестве дополнительного параметра к каждому запросу. Конечно, это увеличит вашу производительность. Вы можете решить эту проблему с разделами оракула. ​​