tukreb, пожалуйста, изучите вопрос прежде чем писать такие глупости. Нормальные формы - это требования предъявляемые только к реляционным базам данных.
Именно поэтому базы и делят на типы: реляционные и не таковые. В первых данные хранятся в таблицах, что накладывает определённые обязательства при разметке. Если бы всё было так просто, то к чем все эти таблицы были бы нужны? Можно было бы всё скинуть в один JSON в одной таблице в одной ячейке и радоваться жизни. Но вы же так не делаете. Вы заботитесть об отношениях, индексах, поисках, оптимизациях и т.д.
tukreb, потому что хранить JSON в MySQL это нарушение первой нормальной формы. Это если принципиально хранить именно JSON, что является спорным решением в данном случае.
Я уже молчу о том, что когда вы на реальном проекте столкнётесь даже в 8 версии с JSON-полем у вас такие проблемы огромные появятся при глубоких JOIN запросах и аналитике.
returnZero, должен, но вы поймите, что без блока catch ошибка не отлавливается в принципе, а падает сразу в самый верх, что приводит к завершению программы. В случае с catch ошибка отлавливается и программа НЕ завершается и продолжается выполнятся, что и приводит выполнение к блоку finally.
Это тоже самое, что написать обычный код, без вообще конструкций try-finally. В try-catch ключевое не finally, а catch.
returnZero, у вас программа завершается ДО того, как выполнение доходит до finally. Вы catch ошибки сделайте и тогда finally выполнится. А так у вылетает программа ещё ДО того, как вы достигли блока finally.
GJmYIF, пишите решение самостоятельно, если вас дизайн смущает. Никто вам гарантий никаких никогда бесплатно не даст. Да и за деньги тоже гарантий никаких быть не может, что ваши СМС никуда не утекут.
Дмитрий Баскаков, не забудьте ещё посмотреть в сторону православного Диадока, если планируете работать в России. Там, вроде как, ещё функционал подписания документов из коробки за небольшую плату.
Ну и полистайте для общего развития сервисы, с которыми интегрируется Диадок: https://www.diadoc.ru/integrations - все они нужны для работы с документами, возможно что-то из этого облегчит задачу вам.
Дмитрий Баскаков, ну, с заполнением проблем возникнуть не должно. Ищите по файлу "жёлтые места" и от контекста заполняете своими данными. Важно, чтобы клиенты правильно готовили файлы, потому что формат .doc очень привередливый и может местами выдавать странности, которые для человека будут выглядеть нормально абсолютно.
Далее, отправляете. Получаете в зад документ, и сверяете с тем, что отправляли. Если не сходятся ключевые моменты - значит, документ изменили. Можете сверять по ключевым суммам текста и использовать алгоритмы анализа текста разной степени извращённости.
Скан сверить будет сложнее - машинное зрение или что ещё МЛщики выдумают. Вопрос в цене и специалистах.
Можно делать всё на пыхе, как вы указали в теге. Есть PHPOffice, его мощностей хватит точно. Но, для сравнения двух картинок, возможно, придётся обратиться к Python.
Если вы можете повлиять на шаблоны самих документов - рекомендую расставить опорные визуальные точки для будущих упрощений. Наподобие тех, что в бланках ЕГЭ используются, если встречались когда-либо. Так и скан будет проще сверить, и ориентироваться в блоках документа программно будет несколько элегантнее.
Недавно не пет-проекте тоже отвалились все ссылки. Открываются только если номер есть в контактах.
Решения так и не нашли, в документации всё по-старому, в чейнджлоге новостей никаких, хотя есть анонс новой системы ссылок.
verygoodboy, у вас проблемы с пониманием того, зачем нужно and в начале выражения. Это банальные условия. И/ИЛИ, почитайте о SQL запросах, чтобы понимать о чём идёт речь.
