#java #hibernate #spring-data-jpa #spring-data #data-modeling
#java #переход в спящий режим #spring-data-jpa #spring-данные #моделирование данных
Вопрос:
Недавно я столкнулся с моделью схемы, подобной этой
Структура выглядит точно так же, я просто переименовал с именем объекта, таким как Table (*), начиная с таблицы C, все таблицы содержат около 200 столбцов, от C до L
Причина публикации этого в том, что я никогда раньше не сталкивался с подобной структурой, если кто-нибудь, кто уже сталкивался с подобным или работал с подобным или более сложным, чем это, пожалуйста, поделитесь своей идеей,
-
Наличие подобной структуры хорошо или плохо, и почему?
-
Предположим, нам нужен API для сохранения данных для структуры таблицы, подобной этой, как спроектировать API
-
Как мы собираемся управлять транзакциями во всех этих таблицах
-
В сервисном коде есть несколько случаев, когда нам может потребоваться получить данные из этих таблиц и перенести во внешнюю систему. Проблема здесь в том, что внешняя система принимает запрос в структуре flatten, а не в иерархии, которая у нас есть, как упоминалось выше. Если эти данные необходимо перенести во внешнюю систему, как мы можем управлять маршалингом и отменять маршалинг
-
И последнее, но не менее важное: API, который будет управлять подобными данными, может потреблять не менее 2 тыс. в день.
Что вы думаете по этому поводу, я не знаю точно, зачем нам это нужно, это требует подробного обсуждения, и нам нужно разделить вещи.
Если я рассматриваю Spring Data JPA, переходите в спящий режим. Какие все это вещи, которые мне нужно учитывать,
Что еще более важно, значения строк всех этих таблиц будут ограничены на основе идентификатора владельца / идентификатора арендатора, поэтому данные должны быть согласованы во всех таблицах.
Комментарии:
1. Пожалуйста, не форматируйте текст как код, он не читается, вы пробовали сами прочитать свой вопрос?
2. @perissf. Я не проверял после публикации, я отредактировал ее снова. При вставке изображения содержимое ниже преобразуется в КОД. Если все еще не ясно, дайте мне знать. Я попытаюсь повторить вопрос, чтобы охватить более широкую аудиторию.
3. Хорошо, теперь форматирование в порядке. Не могли бы вы, пожалуйста, расширить пункт 1, чтобы сделать его не вызывающим вопросов? Объясните лучше структуру, показанную на рисунке, и не спрашивайте, хороша она или плоха, вместо этого спросите, есть ли у структуры какие-то функции или нет (какие функции?). Добавьте код. И не задавайте много вопросов в одном сообщении. Только один
Ответ №1:
Я не могу комментировать общий аспект структуры, поскольку это довольно специфично для домена, и нужно было бы знать, почему была выбрана эта структура, чтобы иметь возможность сказать, хороша она или нет. В любом случае, вы, вероятно, все равно не сможете это изменить, так зачем беспокоиться о том, хорошо это или нет?
Сказав это, с такой моделью есть несколько аспектов, которые вам следует рассмотреть:
- При обновлении данных очень важно обновлять только те столбцы, которые действительно изменились, чтобы избежать уничтожения индекса и позволить БД использовать свободное хранилище на страницах. Это проблема производительности, которая обычно возникает при использовании Hibernate с такими моделями, поскольку Hibernate обычно обновляет все «обновляемые» столбцы, а не только «грязные». Однако есть возможность выполнять динамические обновления. Без динамических обновлений вы могли бы создавать на несколько iOS больше за обновление и, таким образом, сохранять блокировки в течение более длительного времени, что влияет на общую масштабируемость.
- При чтении данных очень важно не использовать выборку соединения по умолчанию, поскольку это может привести к увеличению размера результирующего набора.