lair, соглашусь, в чем то вы правы. Приятно, когда конструктивная критика.
У компании один склад в Калининграде, второй в Иркутске. И как время выдачи товара фиксировать будем?
Согласен, это проблема. Вы заставили меня задуматься над ней. Но она точно не решится индивидуальной постановкой UTC сотруднику. Она решится индивидуально постановкой UTC складу! Нельзя чтобы данные склада отображались в UTC сотрудника, ведь для каждого сотрудника дата-время приема или выдачи товара будет отображаться разное — чего быть не должно (оба позвонят начальнику и скажут: один что товар выдан в 10.00, другой что в 12.00 :) и кому верить?). При этом на UTC компании это тоже не должно быть завязано — оно может быть совершенно другим. Т.е. склад — это просто отдельный модуль с индивидуальным UTC у каждого склада.
Потом есть еще одна причина почему нельзя давать сотрудникам индивидуальный UTC, и он должен быть у компании. В частности у меня в системе можно помимо подразделений объединять сотрудников в группы, например в одном подразделении службы сети связи может быть группа сотрудников занимающийся телефонией, группа занимающиеся интернетом, телевидением и т.д. И можно например настроить чтобы задача с типом интернет пришла в это подразделение автоматически данной группе, и даже распределилась ее сотрудником по какому-то алгоритму. Может так быть, что в группу объединяются сотрудники из разных подразделений, но работающие над одной задачей каждый со своей стороны. Для этих групп могут ставиться задачи именно на группы со многими различными алгоритмами распределения, на группы могут формироваться графики работ (именно группы). Есть для групп SCRUM доски.
И вот представьте ситуацию, у одного сотрудника из группы стоит один UTC, а у другого другой! И какой при этом UTC отображать в графике группы в которую входят оба сотрудника? Это просто билеберда получится.
При этом я согласен с вами, что если один работает в Калининграде а второй в Иркутске… возможно надо просто глубже делать деление системы, вводит понятия офисов, где должно быть свое UTC и при этом запрещать программно объединять сотрудников из разных офисов. В общем действительно надо подумать.
Тут еще видимо есть у меня и дополнительная проблема, у меня в системе встроенный язык программирования (свой) и вся внутренняя кухня аккаунта сделана на нем, а все php-шное — это фактически интерпретатор, поэтому индивидуальный UTC на каком-то модуле должен реализовываться на уровне программирования на внутреннем языке, а не на интерпретаторе или базе данных.
Но вы действительно правы, рано или поздно вопрос разных UTC в каких-то модулях в рамках одной компании может встать и над этим надо подумать. Но так вот в лоб эта проблема не решается т.к. есть миллион дополнительных нюансов.
Пока я все таки считаю свой подход (UTC на компанию) правильным, в данной ситуации, но возможно его придется глубже модернизировать.
Спасибо за конструктивную критику. Она действительно полезна.
По поводу
А теперь представьте, что вам надо посчитать продолжительность выполнения задачи, которая начата до перевода времени с летнего на зимнее, а закончена — после.
Если будет необходим такой подсчет, то такой его нюанс можно реализовать программно. Момент перевода времени известен, сделать IF в процедуре, например если время перевода попадет между датами начала и конца — прибавить к продолжительности час (или вычесть — по ситуации). В общем тут я проблемы не вижу.
1. Возможно мы неправильно друг друга поняли. Я подумал что UI по вашему это Update и Insert.
Смысл в том что все даты в добавлениях и апдейтах делаются через эти view, а в селекте нам уже не нужна математика никакая… там уже дата записана с учетом часового пояса.
2. Если мы рассматриваем мою систему, то тут не совсем корректно сопоставление пользователи — часовые пояса. Есть компании, у которых есть сотрудники. Каждой компании выдается аккаунт и вот на этот аккаунт своя база данных и тут можно выставлять часовой пояс. Все сотрудники компании которые работают в ее аккаунте, работают с настройками компании в целом, т.е. с часовым поясом который настроен у компании.
Ну так и сделано, в UI и делается собственно. А в селекте уже никаких расчетов делать не надо, он просто получает уже нужную дату, т.к. она записана в базе при UI. В селекте может тоже использоваться, например в некоторых фильтрах по умолчанию, но это все обернуто в процедуру внутри БД обычно, а там везде через view любая текущая дата.
У юзера сейчас рисуется допустим 12:00 для какой-то сущности, если юзер меняет таймзону (допустим соседнюю на час) то он увидит теперь везде 13:00? Правильно же?
Нет, юзер увидит 12.00 везде. В старых записях все останется по прежнему. Но новая запись будет не 12.01 а уже 13.01 в случае +1 в таймзоне.
Вернее в селекте в некоторых случаях тоже может использоваться эти view, например в каких-то фильтрах по умолчанию подставляться. Но у меня в реализации этого нет проблем, т.к. эти параметры вшиты во внутренний язык программирования аккаунта, поэтому пользователь не будет задумываться и даже видеть эти внутренние процессы напрямую, для него просто будет текущая дата-время и все.
Нет, view используется при запаси или изменении данных. Селект при этом будет обычный, и в нем уже будет время пользователя. В этом то и преимущество. Никакой дополнительной математики при выводе данных.
Если вы боитесь что при изменении часового пояса может получится белеберда с записями в старом часовом поясе, то во первых такие изменения делает только администратор аккаунта, во вторых это как правило разово (разве что компания решит куда-то переехать), в третих ведутся логи изменений, т.е. можно посмотреть когда было изменение часового пояса и с какого на какой и понять что откуда растет. Я в этом не вижу проблемы. Ну зачем компании больше одного раза менять часовой пояс? Они же сами себе хаос делают…
это облачная платформа erp-platforma.com, с системой автоматизации для предприятий, типа битрикса если в курсе что это такое, только круче, т.к. есть встроенный язык программирования и каждый пользователь может сам настраивать свою БД или веб интерфейс в аккаунте, ну и куча фишечек и плюшечек типа SCRUM досок, программируемого API и т.п. + универсальная система задач, которая подходит даже для провайдеров. Но это не суть важно т.к. все настолько универасально, что каждый пользователь может создать себе любой модуль сам, хоть бухгалтерию написать…
Т.к. все универсально и индивидуально, то каждому пользователю и выделяется своя БД, вернее даже 4 штуки, основная, файловая, для безопасных ссылок и бд для логов. Я некоторые из технических реализаций этих вещей в следующих статьях буду описывать. Еще много всего интересного можно написать, следующая думаю будет звучать «Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных (чтобы основная база данных не засорялась мусором и не росла)» — интереснейшая вещь была с технической точки зрения.
View — так проще, как в запросе вы процедуру планируете использовать, left join? это неудобно, а тут просто вместо например timestamp пишете d_timestamp и все работает.
Это сложно. Представляете в 3 мб php кода (половина их которого гигантские sql запросы) Вам надо везде делать операции преобразования времени! В детсяти тысячах мест! А так Вам не надо задумываться над всем этим, все в базе данных решено уже. Да и лишние операции, быстродействие ниже и т.д. (хоть это и копейки). И например у нас реализовано программируемое API, т.е. пользователь может в своей БД создать триггер специальный, который передаст инфорамцию во вне. В этом случае там будет время по МСК? Или принимать данные извне как? В общем много причин почему сделано так.
Но я как бы не претендую на правильность. Я просто описал способ как это можно сделать, кому-то понравится, а кто-то придумает как сделать по своему. Но данный способ оказался наиболее простым и эффективным.
Ну это неверное зависит от величины проекта. Вот представьте, у Вас один сервер с файрбердом, на нем 1000 баз пользователей, и у каждого пользователя его данные должны отображаться в его часовом поясе (который он настроит). При этом у вас php кода самой системы 3 мегабайта и половина из них запросы в БД, куча процедур и триггеров в каждой из БД, причем структура у каждого пользователя может отличаться, т.к. есть встроенный язык программирования для пользователей (аля как в 1С только немного глубже и через веб). И вы хотите в каждом месте делать доп манипуляции с датой? Это будет жесть. Механизм должен быть универсальный и простой.
Большое спасибо за информацию! Дело сдвинулось с мёртвой точки. Только эти рекомендации до конца не помогли. Получилось только когда помимо включения Legacy_Auth, скачал дистрибутив третьего под win32, и в ibexpert вместо gds32 подставил fbclient.dll из дистрибутива. С php так и не решилось, не работает. Буду экспериментировать, попробую веб сервер на машину с firebird 3 накатить, посмотрю что выйдет из этого.
Поставил Linux AMD64 Firebird-3.0.0.32483-0.amd64.tar.gz
Прямо беда какая-то, убил весь вечер, так и не сделал. Телнетом 3050 порт видит слюбого сервера, из isql с другого сервера (тоже с установленным firebird 3.0) коннектиться без проблем к базе, gbak-ом база извлеклось… но, ни из ibexperta, ни из php (причем с разных серверов, и виндовый и линуксовый, на линкуксе даже php5-interbase обновил) никак. Вообще никак не коннектится, всегда ошибка «connection rejected by remote interface».
В общем работать можно только из /opt/firebird/bin/isql при установленном firebird 3.0. Толку от такого обновления никакого…
Согласен, это проблема. Вы заставили меня задуматься над ней. Но она точно не решится индивидуальной постановкой UTC сотруднику. Она решится индивидуально постановкой UTC складу! Нельзя чтобы данные склада отображались в UTC сотрудника, ведь для каждого сотрудника дата-время приема или выдачи товара будет отображаться разное — чего быть не должно (оба позвонят начальнику и скажут: один что товар выдан в 10.00, другой что в 12.00 :) и кому верить?). При этом на UTC компании это тоже не должно быть завязано — оно может быть совершенно другим. Т.е. склад — это просто отдельный модуль с индивидуальным UTC у каждого склада.
Потом есть еще одна причина почему нельзя давать сотрудникам индивидуальный UTC, и он должен быть у компании. В частности у меня в системе можно помимо подразделений объединять сотрудников в группы, например в одном подразделении службы сети связи может быть группа сотрудников занимающийся телефонией, группа занимающиеся интернетом, телевидением и т.д. И можно например настроить чтобы задача с типом интернет пришла в это подразделение автоматически данной группе, и даже распределилась ее сотрудником по какому-то алгоритму. Может так быть, что в группу объединяются сотрудники из разных подразделений, но работающие над одной задачей каждый со своей стороны. Для этих групп могут ставиться задачи именно на группы со многими различными алгоритмами распределения, на группы могут формироваться графики работ (именно группы). Есть для групп SCRUM доски.
И вот представьте ситуацию, у одного сотрудника из группы стоит один UTC, а у другого другой! И какой при этом UTC отображать в графике группы в которую входят оба сотрудника? Это просто билеберда получится.
При этом я согласен с вами, что если один работает в Калининграде а второй в Иркутске… возможно надо просто глубже делать деление системы, вводит понятия офисов, где должно быть свое UTC и при этом запрещать программно объединять сотрудников из разных офисов. В общем действительно надо подумать.
Тут еще видимо есть у меня и дополнительная проблема, у меня в системе встроенный язык программирования (свой) и вся внутренняя кухня аккаунта сделана на нем, а все php-шное — это фактически интерпретатор, поэтому индивидуальный UTC на каком-то модуле должен реализовываться на уровне программирования на внутреннем языке, а не на интерпретаторе или базе данных.
Но вы действительно правы, рано или поздно вопрос разных UTC в каких-то модулях в рамках одной компании может встать и над этим надо подумать. Но так вот в лоб эта проблема не решается т.к. есть миллион дополнительных нюансов.
Пока я все таки считаю свой подход (UTC на компанию) правильным, в данной ситуации, но возможно его придется глубже модернизировать.
Спасибо за конструктивную критику. Она действительно полезна.
По поводу
Если будет необходим такой подсчет, то такой его нюанс можно реализовать программно. Момент перевода времени известен, сделать IF в процедуре, например если время перевода попадет между датами начала и конца — прибавить к продолжительности час (или вычесть — по ситуации). В общем тут я проблемы не вижу.
Смысл в том что все даты в добавлениях и апдейтах делаются через эти view, а в селекте нам уже не нужна математика никакая… там уже дата записана с учетом часового пояса.
2. Если мы рассматриваем мою систему, то тут не совсем корректно сопоставление пользователи — часовые пояса. Есть компании, у которых есть сотрудники. Каждой компании выдается аккаунт и вот на этот аккаунт своя база данных и тут можно выставлять часовой пояс. Все сотрудники компании которые работают в ее аккаунте, работают с настройками компании в целом, т.е. с часовым поясом который настроен у компании.
Нет, юзер увидит 12.00 везде. В старых записях все останется по прежнему. Но новая запись будет не 12.01 а уже 13.01 в случае +1 в таймзоне.
Если вы боитесь что при изменении часового пояса может получится белеберда с записями в старом часовом поясе, то во первых такие изменения делает только администратор аккаунта, во вторых это как правило разово (разве что компания решит куда-то переехать), в третих ведутся логи изменений, т.е. можно посмотреть когда было изменение часового пояса и с какого на какой и понять что откуда растет. Я в этом не вижу проблемы. Ну зачем компании больше одного раза менять часовой пояс? Они же сами себе хаос делают…
Т.к. все универсально и индивидуально, то каждому пользователю и выделяется своя БД, вернее даже 4 штуки, основная, файловая, для безопасных ссылок и бд для логов. Я некоторые из технических реализаций этих вещей в следующих статьях буду описывать. Еще много всего интересного можно написать, следующая думаю будет звучать «Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных (чтобы основная база данных не засорялась мусором и не росла)» — интереснейшая вещь была с технической точки зрения.
View — так проще, как в запросе вы процедуру планируете использовать, left join? это неудобно, а тут просто вместо например timestamp пишете d_timestamp и все работает.
Но я как бы не претендую на правильность. Я просто описал способ как это можно сделать, кому-то понравится, а кто-то придумает как сделать по своему. Но данный способ оказался наиболее простым и эффективным.
Прямо беда какая-то, убил весь вечер, так и не сделал. Телнетом 3050 порт видит слюбого сервера, из isql с другого сервера (тоже с установленным firebird 3.0) коннектиться без проблем к базе, gbak-ом база извлеклось… но, ни из ibexperta, ни из php (причем с разных серверов, и виндовый и линуксовый, на линкуксе даже php5-interbase обновил) никак. Вообще никак не коннектится, всегда ошибка «connection rejected by remote interface».
В общем работать можно только из /opt/firebird/bin/isql при установленном firebird 3.0. Толку от такого обновления никакого…