Ну на мой взгляд это как раз овер-инженеринг :) но как говорится каждому свое. Я в большей степени все таки по БД специализируюсь чем по вебу. Поэтому больше решений в структуре БД.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам. Натворить делов могут. Думаю с точки зрения облачной платформы доступной всем — такой подход неприемлем.
Ну вообще как-то мы очень далеко вылезли из темы статьи. Предлагаю все таки вернуться. Мы рассматриваем темы базы данных, а не веб интерфейсов :)
Javascript имелся ввиду.
Я объясню свою позицию по данному вопросу если очень интересно.
Например у меня в бразуере стоит NoScript, и когда я захожу на какой-то сайт, естественно скрипты не запускаются. И вот знаете, очень печально зачастую все выглядит, хорошо если хоть что-то отображается хоть и криво косо, зачастую вообще просто белая страница и понять что там вообще невозможно.
Я считаю что сайт должен без javascript полностью сохранять свою функциональность, ничего не должно наезжать друг на друга или не отображаться если скрипты в браузере отключены. Скрипты должны только дополнять красивости и плюшечки без которых можно обойтись. Сделать сайт полностью на javascript — ну на мой взгляд это просто дурной тон (простите меня специалисты по java, я против вас как специалистов ничего не имею, но вот реально очень печально такие сайты выглядят).
Про часовые пояса — я не вижу смысла комментировать. По моему уже все сказано. Да и из другой статьи это. Предлагаю все таки там это обсуждать.
С какими-то высказываниями я согласен, все доводы я услышал и выводы сделаны, и я действительно в последующей разработке буду кое что новое учитывать, но повторюсь, нельзя в лоб давать каждому пользователю менять свой часовой пояс, только компания целиком или дробить до офиса или склада — иначе будет белеберда в работе т.к. есть рабочие группы, есть много других нюансов. А в рамках темы статьи, как сделать именно на базы в рамках одного сервера запись в разной временной зоны — на мой взгляд нет решения проще.
Почему люди негативно это восприняли — ну странно на самом деле. Хотя за некоторые конструктивные комментари — спасибо. Лично я посмотрел на проблему немного с другой стороны.
И как вы изменения данных по цепочке триггеров будите логировать?
Например пользователь из интерфейса нажимает на кнопку, которая запускает процедуру в БД, в этой процедуре выполняется добавление-изменение данных в 10 таблицах, в 5 из этих таблиц еще срабатывают триггеры, которые меняют данные еще в каких-то таблицах.
И что за логи вы запишите из интерфейса?
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 дергается такая-то процедура, в 12.30 другая, а в 15.00 третья. Дергается все это универсальным скриптом, который просто по времени дергает те или иные процедуры (какие пользователь укажет) в которых может меняться неизвестное количество данных в нескольких таблицах. Как в этом случае собираетесь из внешнего скрипта логировать изменения?
Я пример писал, вы можете обозвать как угодно.
Штатной репликации в файрберде нет. Есть программы с реализацией репликации. У этих ребят вроде есть насколько я знаю http://www.ibase.ru/hqbird/
Насколько я знаю, TRUNCATE TABLE в файрберде нет. В ibexpert есть команда «Empty Table» — но для меня загадка как она работает. Если кто в курсе по empty, буду благодарен за описание.
rico_spb — вы хотите сказать что сможете сделать rollback внешней таблицы?
Вот вам вырезка из мануала по файрберду
Необязательное предложение EXTERNAL [FILE] указывает, что таблица хранится
вне базы данных во внешнем текстовом файле. Столбцы таблицы, хранящейся во
внешнем файле, могут быть любого типа за исключением BLOB и массивов с любым
типом данных. Над таблицей, хранящейся во внешнем файле, допустимы только
операции добавления новых строк (INSERT) и выборки (SELECT) данных. Операции
же изменения существующих данных (UPDATE) или удаления строк такой таблицы
(DELETE) не могут быть выполнены.
Если вы импортируете данные из таблицы запросом, все у вас будет хорошо. А вот когда идет интенсивная запись из триггера например… данные теряются (как я убедился). Я долго не мог понять что же за чудеса творятся, запись может произойти, а может и не произойти. Можете самостоятельно провести данные эксперименты. (я правда на firebirde 2.5 еще их проводил, но в третем думаю с этим ничего не изменилось)
Внешние таблицы хороши для переноса больших массивов информации из одной БД в другую. Тут у вас все получится. Использовать же их в онлайне — терять данные.
Плюс отмечу, что для данной задачи подход через внешние таблицы не подходит, ибо в них нельзя blob поля записывать, а сделать одну таблицу под все свои данные не получится ибо надо заранее знать их формат. Вы не можете сделать мегавнешнюю таблицу под все свои данные, тем более что пользователь может, у меня в частности, придумывать еще и свои. Кроме блоба тут ничего не подойдет.
Кстати не так давно довелось увидеть базу 1С, у них реально схожее решение с моим, только идентификаторы более навороченные в таблицах и полях (со всякими буквенными приставками типа _Fld8005_RTRef) и служебные поля естественно другие. У меня они числовые в целом. Где там у них конфиги всего этого хранятся я сходу тогда не понял, надо почитать как-нибудь.
Извиняюсь, писал из головы, модератора у меня нет. Поправил «PACET» всех смущавший.
Давайте споры по поводу UTC перенесем в ту статью. Я никому мозг не выношу, я описал конкретный способ который работает и обосновал почему каждому юзеру делать индивидуальный часовой пояс неправильно, а он должен быть на компанию, или как минимум на офис или склад.
barker — не понимаю в чем у вас проблема. Я пишу не про свою платформу, а про техническую часть, как можно реализовать те или иные вещи. То о чем я пишу — реализовано мной на практике. Я делюсь конкретным решением тех проблем, с которыми мне пришлось столкнуться и которые нигде не озвучены. Эти статьи для людей, которым будут эти темы интересны, у кого стоят похожие задачи. Если вам данные темы не интересны — читайте то, что вам интересно. Про UTC — это немного не та статья, вам не кажется? Вы можете в той статье спокойно оставлять свое недовольство. Та статья про то, как реализовать конкретную вещь, а не про личное мнение большинства комментаторов, как по их мнению должно быть устроено ведение часовых поясов. Сколько людей столько и мнений. Я все мнения прочитал и из некоторых отметил для себя полезные вещи.
Конструктивную критику я приветствую, потому что это дает возможность взглянуть на проблемы под другим углом и это действительно полезно. Никакого троллинга тут нет. Я вполне серьезно это написал.
Признаюсь, о таком подходе не слышал. Почитал про суть подхода ES, действительно интересно. Я так понял, что там нет update и delete, а при каждом изменении создается новая копия данных. Т.е. в базе всегда храниться вся цепочка истории.
Первое что приходит на ум, это огромнейшая избыточность. Но мне конечно надо переварить такой подход, поэтому пока не берусь что-то говорить по этому поводу. Возможно такой подход в каких-то случаях действительно можно эффективно использовать.
Ну на самом деле на php у меня — интерпретатор, структура конфигурации аккаунта хранится в самой базе и интерпретируеся при выводе страницы, пользователю предоставляется специальный язык программирования для конфигурирования аккаунта (и базы данных и веба), вот там как раз создаются и компилируются процедуры и триггеры в БД.
В php как вы описали — делать не вариант, учитывая то, что пользователь строит сам конфигурацию, вы никогда не угадаете что это дата которую надо форматнуть (вернее угадаете, но не понятно зачем такие сложности то вообще и дополнительное процессорное время). Если так и делать то надо обрабатывать не результаты вывода query(), а в самом поле sql. Т.е. на уровне компилирования процедур на внутреннем языке. Собственно, грубо говоря, так и сделано, только через VIEW.
Почему неправильно делать именно каждому пользователю свой UTC (а надо делать компании) я описывал уже подробно «mail-online 17 декабря 2016 в 15:05» (CTRL-F сделайте)
Кстати, может кто знает, в битриксе, мегаплане, клиентской базе и т.д. есть настойка часового пояса вообще? Я например обыскал все настройки в битриксе — я не нашел… У меня есть такое подозрение, что никто не просто так не делает, а никто вообще не сделал такого в принципе.
Ну она в любом случае накроется если это случиться. Разобраться что за последние 5 лет творилось с часовыми поясами и переходами на летне-зимнее время… так там чет ногу сломит. Но мне кажется это на самом деле не критично, ибо на фоне 5 лет час туда сюда сколько процентов занимает? Час это 1/43800. Это потеря точности 0.0022831%
Тут конечно вопрос что вам необходимо, но проработав 10 лет в телекоме я никогда не сталкивался с тем чтобы делать подобные анализы и тем более со 100% точностью. Детализации делали, да, но там юникстайм который был на оборудовании и никто не заморачивался. В случае перехода на зимнелетнее время получалось что траифк писался 2:59, потом 2:00. Грубо говоря час накладывался друг на друга (или был промежуток в другом случае)
Нет. Если мы рассматриваем мой случай, то таймзона меняется для аккаунта. Аккаунт выдается для компании в которой работают сотрудники, и на этот аккаунт как раз выделяется база данных в которых прописываются данные view. Если оба сотрудника (юзера) работают в этом аккаунте, то время их записи будет отображаться в таймзоне аккаунта. Если стоит таймзона Челябинска (+5) и юзер из москвы сделал запись в 12:00 (+3) по своему времени, то в БД запись будет 14:00 и откуда бы и кто бы не смотрел это будет запись 14:00 всегда. Всегда в UTC Челябнска откуда бы она сделана не была.
Ну если мы рассматриваем мою систему, то есть аккаунт компании, аккаунту выделяется база данных и в настройках можно выставить часовой пояс (для компании). При изменении настроек сформируются соответствующие view в БД и будет в дальнейшем писаться соответствующее время, где бы сотрудник не находился, хоть в антарктиде если там есть интернет. В общем неважно где вы физически, время будет — тот момент когда вы сделаете запись по московскому времени (в моем случае) скорректированное до часового пояса из настроек.
Я не претендую на то что это единсвенно-правильный вариант, каждый его реализует все равно по своему. Статью я написал потому, что в свое время я не нашел нигде описанного способа как такое сделать и сделать это на практике у меня получилось. Может кому-то пригодиться если будет стоять похожая задача.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам. Натворить делов могут. Думаю с точки зрения облачной платформы доступной всем — такой подход неприемлем.
Javascript имелся ввиду.
Я объясню свою позицию по данному вопросу если очень интересно.
Например у меня в бразуере стоит NoScript, и когда я захожу на какой-то сайт, естественно скрипты не запускаются. И вот знаете, очень печально зачастую все выглядит, хорошо если хоть что-то отображается хоть и криво косо, зачастую вообще просто белая страница и понять что там вообще невозможно.
Я считаю что сайт должен без javascript полностью сохранять свою функциональность, ничего не должно наезжать друг на друга или не отображаться если скрипты в браузере отключены. Скрипты должны только дополнять красивости и плюшечки без которых можно обойтись. Сделать сайт полностью на javascript — ну на мой взгляд это просто дурной тон (простите меня специалисты по java, я против вас как специалистов ничего не имею, но вот реально очень печально такие сайты выглядят).
Про часовые пояса — я не вижу смысла комментировать. По моему уже все сказано. Да и из другой статьи это. Предлагаю все таки там это обсуждать.
С какими-то высказываниями я согласен, все доводы я услышал и выводы сделаны, и я действительно в последующей разработке буду кое что новое учитывать, но повторюсь, нельзя в лоб давать каждому пользователю менять свой часовой пояс, только компания целиком или дробить до офиса или склада — иначе будет белеберда в работе т.к. есть рабочие группы, есть много других нюансов. А в рамках темы статьи, как сделать именно на базы в рамках одного сервера запись в разной временной зоны — на мой взгляд нет решения проще.
Почему люди негативно это восприняли — ну странно на самом деле. Хотя за некоторые конструктивные комментари — спасибо. Лично я посмотрел на проблему немного с другой стороны.
Например пользователь из интерфейса нажимает на кнопку, которая запускает процедуру в БД, в этой процедуре выполняется добавление-изменение данных в 10 таблицах, в 5 из этих таблиц еще срабатывают триггеры, которые меняют данные еще в каких-то таблицах.
И что за логи вы запишите из интерфейса?
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 дергается такая-то процедура, в 12.30 другая, а в 15.00 третья. Дергается все это универсальным скриптом, который просто по времени дергает те или иные процедуры (какие пользователь укажет) в которых может меняться неизвестное количество данных в нескольких таблицах. Как в этом случае собираетесь из внешнего скрипта логировать изменения?
Штатной репликации в файрберде нет. Есть программы с реализацией репликации. У этих ребят вроде есть насколько я знаю http://www.ibase.ru/hqbird/
Вот вам вырезка из мануала по файрберду
Если вы импортируете данные из таблицы запросом, все у вас будет хорошо. А вот когда идет интенсивная запись из триггера например… данные теряются (как я убедился). Я долго не мог понять что же за чудеса творятся, запись может произойти, а может и не произойти. Можете самостоятельно провести данные эксперименты. (я правда на firebirde 2.5 еще их проводил, но в третем думаю с этим ничего не изменилось)
Внешние таблицы хороши для переноса больших массивов информации из одной БД в другую. Тут у вас все получится. Использовать же их в онлайне — терять данные.
Плюс отмечу, что для данной задачи подход через внешние таблицы не подходит, ибо в них нельзя blob поля записывать, а сделать одну таблицу под все свои данные не получится ибо надо заранее знать их формат. Вы не можете сделать мегавнешнюю таблицу под все свои данные, тем более что пользователь может, у меня в частности, придумывать еще и свои. Кроме блоба тут ничего не подойдет.
Давайте споры по поводу UTC перенесем в ту статью. Я никому мозг не выношу, я описал конкретный способ который работает и обосновал почему каждому юзеру делать индивидуальный часовой пояс неправильно, а он должен быть на компанию, или как минимум на офис или склад.
Конструктивную критику я приветствую, потому что это дает возможность взглянуть на проблемы под другим углом и это действительно полезно. Никакого троллинга тут нет. Я вполне серьезно это написал.
Первое что приходит на ум, это огромнейшая избыточность. Но мне конечно надо переварить такой подход, поэтому пока не берусь что-то говорить по этому поводу. Возможно такой подход в каких-то случаях действительно можно эффективно использовать.
В php как вы описали — делать не вариант, учитывая то, что пользователь строит сам конфигурацию, вы никогда не угадаете что это дата которую надо форматнуть (вернее угадаете, но не понятно зачем такие сложности то вообще и дополнительное процессорное время). Если так и делать то надо обрабатывать не результаты вывода query(), а в самом поле sql. Т.е. на уровне компилирования процедур на внутреннем языке. Собственно, грубо говоря, так и сделано, только через VIEW.
Почему неправильно делать именно каждому пользователю свой UTC (а надо делать компании) я описывал уже подробно «mail-online 17 декабря 2016 в 15:05» (CTRL-F сделайте)
Кстати, может кто знает, в битриксе, мегаплане, клиентской базе и т.д. есть настойка часового пояса вообще? Я например обыскал все настройки в битриксе — я не нашел… У меня есть такое подозрение, что никто не просто так не делает, а никто вообще не сделал такого в принципе.
Тут конечно вопрос что вам необходимо, но проработав 10 лет в телекоме я никогда не сталкивался с тем чтобы делать подобные анализы и тем более со 100% точностью. Детализации делали, да, но там юникстайм который был на оборудовании и никто не заморачивался. В случае перехода на зимнелетнее время получалось что траифк писался 2:59, потом 2:00. Грубо говоря час накладывался друг на друга (или был промежуток в другом случае)
Я не претендую на то что это единсвенно-правильный вариант, каждый его реализует все равно по своему. Статью я написал потому, что в свое время я не нашел нигде описанного способа как такое сделать и сделать это на практике у меня получилось. Может кому-то пригодиться если будет стоять похожая задача.