Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.58.113.193] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (3) 1 2 [3] все ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
Цитата JoeUser @ Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность. Всё очень просто. Полная проверка состоит из кучи отдельных, всё это требует больших ресурсов и времени. Но мы проводим её спокойно, не спеша, не трогая основных данных, по запросу, а можно даже дополнительно в фоновом режиме параллельно интерактивной работе. И к тому моменту, когда всё введено, многие проверки уже выполнены (например, что фамилия написана с большой буквы, остальные маленькие, в ней нет цифр, латиницы, двойных пробелов и кавычек-двоеточий). Если какие-то не пройдены - не пытаясь внести данные в БД, мы сразу указываем юзеру на возможные проблемы. Если все они пройдены (а по некритичным юзер сказал, что так и должно быть) - мы пробуем внести данные, и тут проводится не полный комплекс контроля, а только сравнительно дешёвый по ресурсам комплекс проверки ссылочной целостности и непротиворечивости. Более того, ещё до внесения в зависимости от данных мы можем принять решение, например, делать запрос на внесение новой записи в словарную таблицу и получать ИД свежевнесённой записи для подстановки его в остальные запросы, или там нужное значение есть, и следует этот этап вообще похерить и сразу использовать полученное на этапе проверки литератльное значение ИД в следующих запросах. |
Сообщ.
#32
,
|
|
|
Цитата Akina @ Цитата JoeUser @ Если заблокировал, тогда смысл последующих чеках? Блок и так обеспечивает тебе валидность. Всё очень просто. Полная проверка состоит из кучи отдельных, всё это требует больших ресурсов и времени. Но мы проводим её спокойно, не спеша, не трогая основных данных, по запросу, а можно даже дополнительно в фоновом режиме параллельно интерактивной работе. И к тому моменту, когда всё введено, многие проверки уже выполнены (например, что фамилия написана с большой буквы, остальные маленькие, в ней нет цифр, латиницы, двойных пробелов и кавычек-двоеточий). Если какие-то не пройдены - не пытаясь внести данные в БД, мы сразу указываем юзеру на возможные проблемы. Если все они пройдены (а по некритичным юзер сказал, что так и должно быть) - мы пробуем внести данные, и тут проводится не полный комплекс контроля, а только сравнительно дешёвый по ресурсам комплекс проверки ссылочной целостности и непротиворечивости. Более того, ещё до внесения в зависимости от данных мы можем принять решение, например, делать запрос на внесение новой записи в словарную таблицу и получать ИД свежевнесённой записи для подстановки его в остальные запросы, или там нужное значение есть, и следует этот этап вообще похерить и сразу использовать полученное на этапе проверки литератльное значение ИД в следующих запросах. Тогда о5 не понятна выгода. В моем случае все проверки бизнес-логики строятся интерактивно по-диалогово (имена, даты, кавычки ...). В твоем случае все собирается вместе и идет пакетный анализ с указанием недочетов, и последующий быстрый сброс данных, я так понял? Тогда в чем соль? Блокировки без объявления транзакции ты не проведешь (говорю про PostgreSQL, тока что проверил). Поэтому на момент редактирования так же будут висеть открытые IDLE-транзакции. А поэтапный сброс данных или единовременный - не кажется ли тебе, что это аналог вопроса о том, с какой стороны правильнее намазывать бутерброд? |