Диапазоны дат во взглядах - это нормально? - PullRequest
1 голос
/ 07 января 2009

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

Одна из странных вещей в их базе данных состоит в том, что у них есть группа представлений, которые вместо того, чтобы пользователь предоставлял диапазоны дат, которые он хочет видеть, объединяются с (глобальной временной) таблицей TMP_PARM_RANG с началом и Дата окончания. Каждый раз, когда основное приложение начинает обрабатывать запрос, первым делом оно делает это "DELETE FROM TMP_PARM_RANG;" затем вставка в него.

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

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

Ответы [ 9 ]

3 голосов
/ 07 января 2009

Я правильно понимаю?

Есть такой вид:

SELECT * FROM some_table, tmp_parm_rang
  WHERE some_table.date_column BETWEEN tmp_parm_rang.start_date AND tmp_parm_rang.end_date;

Затем в некотором интерфейсе пользователь вводит диапазон дат, и приложение выполняет следующее:

  1. Удаляет все существующие строки из TMP_PARM_RANG
  2. Вставляет новый ряд в TMP_PARM_RANG со значениями пользователя
  3. Выбирает все строки в представлении

Интересно, зафиксированы ли или отменены изменения в TMP_PARM_RANG, и если да, то когда? Это временная таблица или обычная таблица? В основном, в зависимости от ответов на эти вопросы, процесс может быть небезопасным для нескольких пользователей для параллельного выполнения. Можно надеяться, что если бы это было так, они бы уже обнаружили это и обратились к нему, но кто знает?

Даже если это делается поточно-ориентированным способом, внесение изменений в базу данных для простых операций запросов не имеет большого смысла. Эти DELETE и INSERT генерируют redo / undo (или любой другой эквивалент в базе данных, отличной от Oracle), что совершенно не нужно.

Простой и более обычный способ достижения той же цели - выполнить этот запрос, привязав входные данные пользователя к параметрам запроса:

SELECT * FROM some_table WHERE some_table.date_column BETWEEN ? AND ?;
3 голосов
/ 07 января 2009

Если база данных oracle, возможно, это глобальная временная таблица; каждая сессия видит свою собственную версию таблицы и вставки / удаления не влияют на других пользователей.

2 голосов
/ 07 января 2009

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

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

1 голос
/ 07 января 2009

Полагаю, это позволит им поддерживать несколько диапазонов. Например, они могут вернуть все даты между 01.01.2008 и 01.01.2009, 01.01.2006 и 01.01.2007, чтобы сравнить данные 2006 года с данными 2008 года. Вы не могли бы сделать это с одной парой связанных параметров. Кроме того, я не знаю, как Oracle кэширует планы запросов для представлений, но, возможно, это как-то связано с этим? С проверкой столбцов даты как части представления сервер может кэшировать план, который всегда предполагает, что даты будут проверены.

Просто выбрасываю здесь некоторые догадки:)

Также вы написали:

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

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

1 голос
/ 07 января 2009

Лично я предполагаю, что это будет довольно странное происшествие. А из того, что вы говорите, два метода, вызывающих процесс одновременно, могут быть очень интересными.

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

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

0 голосов
/ 07 января 2009

С подходом глобальной временной таблицы GTT, который вы комментируете, используется здесь, этот метод, безусловно, безопасен для многопользовательской системы, так что никаких проблем нет. Если это Oracle, то я бы хотел убедиться, что система либо использует соответствующий уровень динамической выборки, чтобы GTT был правильно соединен, либо чтобы был вызван DBMS_STATS для предоставления статистики по GTT.

0 голосов
/ 07 января 2009

Представления, вероятно, используются в качестве временных таблиц. В SQL Server мы можем использовать переменную таблицы или временную таблицу (# / ##) для этой цели. Хотя создание представлений не рекомендуется экспертами, я создал много их для своих проектов SSRS, потому что таблицы, над которыми я работаю, не ссылаются друг на друга (НИКАКИХ ФК, серьезно!). Я должен обойти недостатки в дизайне базы данных; вот почему я часто использую представления.

0 голосов
/ 07 января 2009

Это звучит как довольно странный алгоритм для меня. Интересно, как это обрабатывает параллелизм - это обернуто в транзакции?

Звучит так, будто кто-то просто не знал, как написать предложение WHERE.

0 голосов
/ 07 января 2009

Они также добавляют одно - в приложении - для генерации следующего уникального значения для первичного ключа?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...