Диапазоны дат во взглядах - это нормально?
https://stackoverflow.com/questions/420948
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Недавно я начал работать в компании с огромным «предприятием». приложение. На моей последней работе я проектировал базу данных, но здесь у нас есть целый отдел архитектуры баз данных, частью которого я не являюсь.
Одна из странных вещей в их базе данных состоит в том, что у них есть группа представлений, которые вместо того, чтобы пользователь предоставлял диапазоны дат, которые он хочет видеть, объединяются с (глобальной временной) таблицей " TMP_PARM_RANG " с начальной и конечной датой. Каждый раз, когда основное приложение начинает обрабатывать запрос, первым делом оно делает это DELETE FROM TMP_PARM_RANG ; " затем вставка в него.
Это кажется странным способом ведения дел, и не очень безопасным, но все остальные здесь, похоже, согласны с этим. Это нормально или мое беспокойство оправдано?
Обновление . Следует отметить, что они используют транзакции и блокировки для каждого клиента, поэтому он защищен от большинства проблем параллелизма. Кроме того, существуют буквально десятки, если не сотни просмотров, все из которых зависят от TMP_PARM_RANG .
Решение
Я правильно понимаю?
Есть такой вид:
SELECT * FROM some_table, tmp_parm_rang
WHERE some_table.date_column BETWEEN tmp_parm_rang.start_date AND tmp_parm_rang.end_date;
Затем в некотором интерфейсе пользователь вводит диапазон дат, и приложение выполняет следующие действия:
<Ол>Интересно, зафиксированы ли или отменены изменения в TMP_PARM_RANG, и если да, то когда? Это временная таблица или обычная таблица? В основном, в зависимости от ответов на эти вопросы, процесс может быть небезопасным для нескольких пользователей для параллельного выполнения. Можно надеяться, что если бы это было так, они бы уже обнаружили это и обратились к нему, но кто знает?
Даже если это сделано потокобезопасным способом, внесение изменений в базу данных для простых операций запросов не имеет большого смысла. Эти DELETE и INSERT генерируют redo / undo (или любой другой эквивалент в базе данных, отличной от Oracle), что совершенно не нужно.
Простой и более обычный способ достижения той же цели - выполнить этот запрос, привязав входные данные пользователя к параметрам запроса:
SELECT * FROM some_table WHERE some_table.date_column BETWEEN ? AND ?;
Другие советы
Если база данных oracle, возможно, это глобальная временная таблица; каждая сессия видит свою собственную версию таблицы и вставки / удаления не влияют на других пользователей.
Для этой таблицы должна быть какая-то деловая причина. Я видел представления с жестко закодированными датами, которые на самом деле были разделенными на части, и они использовали даты в качестве поля для разделения. Я также видел присоединение к столу, как при работе с летним временем, представьте себе представление, возвращающее все действия, которые произошли во время летнего времени. И ничего из этого никогда не удалят и не вставят в таблицу ... это просто странно
Так что или есть более глубокая причина для этого, которую нужно откопать, или это просто что-то, что в то время казалось хорошей идеей, но почему это было сделано таким образом, было потеряно как знание племени.
Лично я предполагаю, что это будет довольно странное происшествие. А из того, что вы говорите, два метода, вызывающих процесс одновременно, могут быть очень интересными.
Обычно диапазоны дат выполняются в виде фильтров в представлении и не управляются внешними значениями, хранящимися в других таблицах.
Единственное оправдание, которое я смог увидеть, это наличие многоэтапного процесса, который выполнялся только один раз за раз, а даты необходимы для нескольких операций в нескольких хранимых процедурах.
Полагаю, это позволило бы им поддерживать несколько диапазонов. Например, они могут вернуть все даты между 01.01.2008 и 01.01.2009, 01.01.2006 и 01.01.2007, чтобы сравнить данные 2006 года с данными 2008 года. Вы не могли бы сделать это с одной парой связанных параметров. Кроме того, я не знаю, как Oracle кэширует планы запросов для представлений, но, возможно, это как-то связано с этим? Если столбцы даты проверяются как часть представления, сервер может кэшировать план, который всегда предполагает, что даты будут проверены.
Просто выкину несколько догадок:)
Кроме того, вы написали:
Я должен упомянуть, что они используют транзакции и блокировки на клиента, так это защищено от большинства параллелизма проблемы.
Хотя это может защитить от проблем согласованности данных из-за параллелизма, это наносит ущерб, когда речь идет о проблемах производительности из-за параллелизма.
Они также добавляют одно - в приложении - для генерации следующего уникального значения для первичного ключа?
Кажется, что понятие общего состояния ускользает от этих людей, или причина общего состояния ускользает от нас.
Это звучит как довольно странный алгоритм для меня. Интересно, как это обрабатывает параллелизм - это обернуто в транзакции?
Мне кажется, что кто-то просто не знал, как написать предложение WHERE.
Представления, вероятно, используются в качестве временных таблиц. В SQL Server мы можем использовать переменную таблицы или временную таблицу (# / ##) для этой цели. Хотя создание представлений не рекомендуется экспертами, я создал много их для своих проектов SSRS, потому что таблицы, над которыми я работаю, не ссылаются друг на друга (НИКАКИХ ФК, серьезно!). Я должен обойти недостатки в дизайне базы данных; Вот почему я часто использую представления.
При использовании подхода с использованием глобальной временной таблицы GTT, который вы комментируете, этот метод, безусловно, безопасен в отношении многопользовательской системы, поэтому проблем здесь нет. Если это Oracle, то я хотел бы проверить, что система либо использует соответствующий уровень динамической выборки, чтобы GTT был правильно соединен, либо чтобы был сделан вызов DBMS_STATS для предоставления статистики по GTT.
