| 
 | 
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Пишем данные в БД, получаем ошибку уникального ключа. [dbMessage:protected] => attempt to store duplicate value (visible to active transactions) in unique index "PERS_IDX1" Problematic key value is (<expression> = 'U4') Поделитесь опытом бработки подобных ошибок. Можно в скрипте обрабатывать наиболее вероятные ошибки и давать вразумительные ответы юзеру. Можно не дублировать логику, писать БД, получать вот такой отлуп. Но как теперь толком объяснить юзеру, в чем причина? У каждого способа свои плюсы/минусы. Посоветуйте с высоты опыта, какой вариант предпочтительней, может удачные практики есть у кого. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 11:07 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryG, Юзера можно побеспокоит только если он явно участвует в формировании этого ключа ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 11:49 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryG, В каждом ЯП свои паттерны хорошего кода. Это как мода. Сегодня это модно, а завтра нет. Например, в ОРМ в шарпе мы получаем ошибки уже от самого ОРМ фреймворка. В java есть деклоративное управления транзакциями и ошибками. Так что идите к программистам. Это слишком низкий уровень для бизнес аналитиков в данной ветке. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 11:54 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGПишем данные в БД, получаем ошибку уникального ключа. [dbMessage:protected] => attempt to store duplicate value (visible to active transactions) in unique index "PERS_IDX1" Problematic key value is (<expression> = 'U4') Поделитесь опытом бработки подобных ошибок. Можно в скрипте обрабатывать наиболее вероятные ошибки и давать вразумительные ответы юзеру. Можно не дублировать логику, писать БД, получать вот такой отлуп. Но как теперь толком объяснить юзеру, в чем причина? У каждого способа свои плюсы/минусы. Посоветуйте с высоты опыта, какой вариант предпочтительней, может удачные практики есть у кого. Пишутся в лог со стектрейсом. Если регулярно выпадают, то заводится бага в Jira. Бага правится - ошибки исчезают. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 12:27 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  БД же возвращает отлуп, что операция не получилась его можно перехватить и отписать юзеру свою мессагу (поскольку там всего 1 причина, её и указываем) а если вас именно беспокоят ошибки, которые бесконтрольно вылетают юзеру в морду то их же можно подавлять (в пхп @)/контроллить (настроить свой обработчик) только так ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 16:01 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  tip78то их же можно подавлять (в пхпво! Ещё один вариант для пхп. Ждем вариант для эрланг) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 16:12 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Я и есть программист ) И размышляю. Стоит ли опираться на ссылочную целостность БД - анализировать ошибки запросов и дальше по обстоятельствам. Другими словами "ошибки при запросах к БД - это нормально". Или не стоит связываться с ссылочной целостностью. Оставить её в покое, как дополнительный защитный уровень. Строить свои проверки корректности данных. Пусть и с помощью доп. запросов проверять наиболее популярные конфликтные ситуации. А ошибку при запросе к БД рассматривать, как "странно, но вы не дожны были увидеть такую ошибку". Пишу Web-приложение на голом php. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 19:33 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryG"странно, но вы не дожны были увидеть такую ошибку". по сути да, поэтому обработчик ошибок шлёт мыло, чтобы сразу ошибку исправлять ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 21:27 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGЯ и есть программист ) И размышляю. Стоит ли опираться на ссылочную целостность БД - анализировать ошибки запросов и дальше по обстоятельствам. Другими словами "ошибки при запросах к БД - это нормально". Или не стоит связываться с ссылочной целостностью. Оставить её в покое, как дополнительный защитный уровень. Строить свои проверки корректности данных. Пусть и с помощью доп. запросов проверять наиболее популярные конфликтные ситуации. А ошибку при запросе к БД рассматривать, как "странно, но вы не дожны были увидеть такую ошибку". Пишу Web-приложение на голом php. Тоска зелёная ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 21:38 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  У меня за сутки выпало более 30000 ошибок. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 21:43 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGМожно в скрипте обрабатывать наиболее вероятные ошибки и давать вразумительные ответы юзеру. «Бла-бла, извините, бла-бла... ждите когда починят». Какой ещё вразумительный ответ можно дать? Ну котика покажите. AndryGУ каждого способа свои плюсы/минусы. Посоветуйте с высоты опыта, какой вариант предпочтительней, может удачные практики есть у кого. Валидация, блокировки. Основная задача, это устранять ошибки, а не покрывать их какими-то «вразумительными» сообщениями и объяснениями. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 22:16 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGДругими словами "ошибки при запросах к БД - это нормально". Нет. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 22:16 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGА ошибку при запросе к БД рассматривать, как "странно, но вы не дожны были увидеть такую ошибку". Рассматривать, как косяк разработчика. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 22:16 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Я имею ввиду ошибки в вводимых данных! Если человек пытается зарегестрировать уже существующий логин, то какой тут косяк разработчика? Ещё пример. "Введите желаемый размер от 17 до 47". А на сервер приходит 63. На поле в БД стоит ограничение "value between 17 and 47". Либо я пишу в БД 63 и получаю ошибку от БД, парсим ответ, выбираем, что не понравилось БД и выдаем персу ответ. Либо в коде перед формированием запроса к БД проверяем значение (дублируем проверку) и выдаем ошибку "укажите допустимый размер" Какие письма. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 22:49 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGЕсли человек пытается зарегестрировать уже существующий логин, то какой тут косяк разработчика? Косяк в том, что он не проверил доступность логина. Косяк разработчика, что он в этом вопросе полагается только на уникальный индекс и работает с ошибками базы данных, как с валидацией. Косяк разработчика, что он не понимает, что такое валидация в принципе, и чем она отличается от констрейтов в базе данных. AndryGЕщё пример. "Введите желаемый размер от 17 до 47". А на сервер приходит 63. На поле в БД стоит ограничение "value between 17 and 47". Либо я пишу в БД 63 и получаю ошибку от БД, парсим ответ, выбираем, что не понравилось БД и выдаем персу ответ. Полная хрень. Ограничения в БД это последний и важный эшелон для обеспечение целостности данных. Но он не является инструментом для проверки корректности вводимой информации. Ни в коем случае. У нас бы за такое был бы серьёзный разговор, а при непонимании, увольнение. Это азы. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 22:54 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGЛибо в коде перед формированием запроса к БД проверяем значение (дублируем проверку) и выдаем ошибку "укажите допустимый размер" Вообще-то не «дублируем проверку», а просто делаем проверку. Это называется валидация. Если в логе увидели ошибку нарушения констрейта, значит где-то накосячили и не сделали проверку. При работе с БД всегда считаем по умолчанию, что никаких констрейтов там нет. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 23:07 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  hVostt, спасибо за объяснения. Пусть и в столь... яркой форме ) Уровень БД - это второй эшелон обороны и не стоит его активно использовать как основной валидатор. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 10.04.2018, 23:54 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryG, Рад помочь! :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 00:51 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  hVosttВообще-то не «дублируем проверку», а просто делаем проверку. Это называется валидация. +1 AndryG, то, о чём Вы пишите - это валидация вводимых данных. Уровень БД - это не второй, а последний эшелон. Если Вы пишите web-приложение, то хорошо бы подумать о валидации на клиенте и валидации на сервере до записи в базу. Почитать об этом пару статей на тему зачем и как лучше делать. К примеру диапазон можно ограничить так: Код: html 1. Если пользователь введёт 63, то получит сообщение об ошибке, приэтом запрос не будет отправлен на сервер. P.S.: и хорошо бы задачу описывать подробнее, а не выкладывать сначала часть размышлений о том, как её решить, опираясь на ссылочную целостность, а потом уточнять о чём речь. Сэкономите себе время. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 07:00 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGЕщё пример. "Введите желаемый размер от 17 до 47". А на сервер приходит 63. На поле в БД стоит ограничение "value between 17 and 47". Либо я пишу в БД 63 и получаю ошибку от БД, парсим ответ, выбираем, что не понравилось БД и выдаем персу ответ. Либо в коде перед формированием запроса к БД проверяем значение (дублируем проверку) и выдаем ошибку "укажите допустимый размер" Если покупатель ввёл 63 при поиске, что Вы собираетесь в БД писать и зачем? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 07:17 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGЕсли человек пытается зарегестрировать уже существующий логин, то какой тут косяк разработчика? Если человек при этом ошибся и указал в email # вместо @, то как Вам помогут ограничения целосности БД? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 07:19 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  skyANA, это и была часть размышлений. (я в курсе про клиентские, серверные проверки данных и назначение каждой из них. Опыт есть) Пишу код уровня "доступа к даным", При повторном прогоне кода создания юзера вылезла ожидаемая ошибка уникальности логина. Тут и появилась мысль использовать это для уменьшения кода валидаторов - не делать некоторые и вылавливать для этого ошибки БД. Судя по ярким ответам, я или потоптался по мозолям или несу ересь ) ещё раз спасибо за ответы. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 10:41 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryGСудя по ярким ответам, я или потоптался по мозолям или несу ересь ) Да, это ересь. Но ересь в данном контексте небесполезная. Ты учишься. Надеюсь, потом сам будешь долго смеяться, каким идиотом раньше был :) Немного в более общем виде - программисты ленивы, что объяснимо, но суть качества в противостоянии лени, в выбивании её из себя. А когда вот так дружелюбно по заднице навставляют, то это вы ещё очень легко отделались :) Выше уже указали - могли бы и уволить. Так что пилите, Шура, пилите, они золотые! ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 12:41 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  AndryG(я в курсе про клиентские, серверные проверки данных и назначение каждой из них. Опыт есть)какого фига тогда вопрос первоклассника? Если голый php значит ошибка от драйвера? Вот и раздели ошибки на уровни и покажи ту что касается юзверя. А доделаешь ли ты потом ДОП валидацию на клинте твои хотелки и проблемы. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 12:43 | 
  
  
  
   | 
||
| 
 
Ссылочная целостность. Проверка данных до записи или обработка ошибок после? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  alex55555Немного в более общем виде - программисты ленивы, что объяснимо, но суть качества в противостоянии лени, в выбивании её из себя. А когда вот так дружелюбно по заднице навставляют, то это вы ещё очень легко отделались :) Выше уже указали - могли бы и уволить. Так что пилите, Шура, пилите, они золотые! Тут не согласен. Лень программиста, это золотая жила в его профессионализме. Программист должен быть достаточно ленив, чтобы избавить себя от монотонного копипаста кода, бесконечного ковыряния в отладке в бесконечном исправлении ошибок. Он должен писать код, который если ломается, то давать максимальную информацию о проблеме, и минимизировать возможность выстрелить себе в ногу. Иногда лень путают с наивной беспечностью и отсутствием опыта. Т.е. вот здесь и сейчас нагавнякал, получил результат какой-то. Вроде выглядит как лень, типа не стал заморачиваться и тратить время на то, чтобы сделать по уму. Но опыт показывает, что потом эти «лентяи» безвылазно делают одну и ту же мудохрень, то, чего можно было не делать, и не тратить на это время совсем. Просто это не так очевидно на коротком отрезке времени. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 11.04.2018, 12:48 | 
  
  
  
   | 
||
| 
 | 

start [/forum/topic.php?fid=33&tid=1547229]:  | 
    0ms | 
get settings:  | 
    10ms | 
get forum list:  | 
    13ms | 
check forum access:  | 
    4ms | 
check topic access:  | 
    4ms | 
track hit:  | 
    61ms | 
get topic data:  | 
    9ms | 
get forum data:  | 
    3ms | 
get page messages:  | 
    56ms | 
get tp. blocked users:  | 
    1ms | 
| others: | 12ms | 
| total: | 173ms | 

| 0 / 0 | 

    Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
    
    
    «На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даете согласие с использованием данных технологий.»
    
    
    ... бла, бла, бла ...