Comments 50
… а в это время другие люди используют Event Sourcing, да.
(или, по крайней мере, очереди событий)
Признаюсь, о таком подходе не слышал. Почитал про суть подхода ES, действительно интересно. Я так понял, что там нет update и delete, а при каждом изменении создается новая копия данных. Т.е. в базе всегда храниться вся цепочка истории.
Первое что приходит на ум, это огромнейшая избыточность. Но мне конечно надо переварить такой подход, поэтому пока не берусь что-то говорить по этому поводу. Возможно такой подход в каких-то случаях действительно можно эффективно использовать.
Первое что приходит на ум, это огромнейшая избыточность. Но мне конечно надо переварить такой подход, поэтому пока не берусь что-то говорить по этому поводу. Возможно такой подход в каких-то случаях действительно можно эффективно использовать.
«LOG_PACET»
— вы серьёзно?
«Таблиц LOG делается 3 штуки. LOG_1 – в первый день данные пишутся сюда, LOG_2 – в следующий день данные пишутся сюда, и т.д. происходит чередование, один день в LOG_1 второй день в LOG_2.»
— точно серьёзно?
удалите статью пока не поздно.
— вы серьёзно?
«Таблиц LOG делается 3 штуки. LOG_1 – в первый день данные пишутся сюда, LOG_2 – в следующий день данные пишутся сюда, и т.д. происходит чередование, один день в LOG_1 второй день в LOG_2.»
— точно серьёзно?
удалите статью пока не поздно.
А разве в firebird нельзя писать логи во внешние таблицы? И дропать ничего не придется.
Изначально пробовал. Но оказалось, что они вне транзакций. Запись происходит через раз. В общем запись не гарантирована.
Запись происходит через раз. В общем запись не гарантирована.Ух, ты!
Похоже, Tortortor выше был прав:
удалите статью пока не поздно.
rico_spb — вы хотите сказать что сможете сделать rollback внешней таблицы?
Вот вам вырезка из мануала по файрберду
Если вы импортируете данные из таблицы запросом, все у вас будет хорошо. А вот когда идет интенсивная запись из триггера например… данные теряются (как я убедился). Я долго не мог понять что же за чудеса творятся, запись может произойти, а может и не произойти. Можете самостоятельно провести данные эксперименты. (я правда на firebirde 2.5 еще их проводил, но в третем думаю с этим ничего не изменилось)
Внешние таблицы хороши для переноса больших массивов информации из одной БД в другую. Тут у вас все получится. Использовать же их в онлайне — терять данные.
Плюс отмечу, что для данной задачи подход через внешние таблицы не подходит, ибо в них нельзя blob поля записывать, а сделать одну таблицу под все свои данные не получится ибо надо заранее знать их формат. Вы не можете сделать мегавнешнюю таблицу под все свои данные, тем более что пользователь может, у меня в частности, придумывать еще и свои. Кроме блоба тут ничего не подойдет.
Вот вам вырезка из мануала по файрберду
Необязательное предложение EXTERNAL [FILE] указывает, что таблица хранится
вне базы данных во внешнем текстовом файле. Столбцы таблицы, хранящейся во
внешнем файле, могут быть любого типа за исключением BLOB и массивов с любым
типом данных. Над таблицей, хранящейся во внешнем файле, допустимы только
операции добавления новых строк (INSERT) и выборки (SELECT) данных. Операции
же изменения существующих данных (UPDATE) или удаления строк такой таблицы
(DELETE) не могут быть выполнены.
Если вы импортируете данные из таблицы запросом, все у вас будет хорошо. А вот когда идет интенсивная запись из триггера например… данные теряются (как я убедился). Я долго не мог понять что же за чудеса творятся, запись может произойти, а может и не произойти. Можете самостоятельно провести данные эксперименты. (я правда на firebirde 2.5 еще их проводил, но в третем думаю с этим ничего не изменилось)
Внешние таблицы хороши для переноса больших массивов информации из одной БД в другую. Тут у вас все получится. Использовать же их в онлайне — терять данные.
Плюс отмечу, что для данной задачи подход через внешние таблицы не подходит, ибо в них нельзя blob поля записывать, а сделать одну таблицу под все свои данные не получится ибо надо заранее знать их формат. Вы не можете сделать мегавнешнюю таблицу под все свои данные, тем более что пользователь может, у меня в частности, придумывать еще и свои. Кроме блоба тут ничего не подойдет.
Так же я приветствую конструктивную критику.По-моему, это всё же тупо троллинг.
Итак, в предыдущей статье про «облачную платформу для автоматизации предприятий», «неограниченно масштабируемую, с огромным числом потенциальных пользователей» и про работу со временем выяснилось, что вы не только совершенно неприемлемо это делаете и даже не понимаете почему так делать нельзя (о чём вам сказали ВСЕ комментаторы), но и даже не понимаете что такое UTC (!!!).
И вы всё же продолжаете «цикл статей»? Это не шутка?
barker — не понимаю в чем у вас проблема. Я пишу не про свою платформу, а про техническую часть, как можно реализовать те или иные вещи. То о чем я пишу — реализовано мной на практике. Я делюсь конкретным решением тех проблем, с которыми мне пришлось столкнуться и которые нигде не озвучены. Эти статьи для людей, которым будут эти темы интересны, у кого стоят похожие задачи. Если вам данные темы не интересны — читайте то, что вам интересно. Про UTC — это немного не та статья, вам не кажется? Вы можете в той статье спокойно оставлять свое недовольство. Та статья про то, как реализовать конкретную вещь, а не про личное мнение большинства комментаторов, как по их мнению должно быть устроено ведение часовых поясов. Сколько людей столько и мнений. Я все мнения прочитал и из некоторых отметил для себя полезные вещи.
Конструктивную критику я приветствую, потому что это дает возможность взглянуть на проблемы под другим углом и это действительно полезно. Никакого троллинга тут нет. Я вполне серьезно это написал.
Конструктивную критику я приветствую, потому что это дает возможность взглянуть на проблемы под другим углом и это действительно полезно. Никакого троллинга тут нет. Я вполне серьезно это написал.
Мне уже не терпится увидеть третий шедевр…
И главное, что пугает — это уже кем-то реализовано на практике.
Основная проблема по статье с часовыми поясами:
UTC — не должен зависеть от часового пояса, локальное время — должно. Смешивая эти два понятия Вы выносите мозги вообще всем.
Проблемы в данном случае:
Манипуляция с тремя таблицами и дополнительными вьюшками… Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Что-то мне подсказывает, что использовать исключительно цифры в названиях таблиц и полей — не очень-то и здоровая идея, которая безумно усложняет поддержку.
«свой встроенный язык программирования в систему» — учитывая всё прочитанное, извините, очень страшно, но безумно интересно увидеть его описание.
LOG_PACET — граммарнаци негодуют (А гугл транслейт распознаёт это как индонезийский и подсказывает перевод — «слизни»)
И главное, что пугает — это уже кем-то реализовано на практике.
Основная проблема по статье с часовыми поясами:
UTC — не должен зависеть от часового пояса, локальное время — должно. Смешивая эти два понятия Вы выносите мозги вообще всем.
Проблемы в данном случае:
Манипуляция с тремя таблицами и дополнительными вьюшками… Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Что-то мне подсказывает, что использовать исключительно цифры в названиях таблиц и полей — не очень-то и здоровая идея, которая безумно усложняет поддержку.
«свой встроенный язык программирования в систему» — учитывая всё прочитанное, извините, очень страшно, но безумно интересно увидеть его описание.
LOG_PACET — граммарнаци негодуют (А гугл транслейт распознаёт это как индонезийский и подсказывает перевод — «слизни»)
Извиняюсь, писал из головы, модератора у меня нет. Поправил «PACET» всех смущавший.
Давайте споры по поводу UTC перенесем в ту статью. Я никому мозг не выношу, я описал конкретный способ который работает и обосновал почему каждому юзеру делать индивидуальный часовой пояс неправильно, а он должен быть на компанию, или как минимум на офис или склад.
Давайте споры по поводу UTC перенесем в ту статью. Я никому мозг не выношу, я описал конкретный способ который работает и обосновал почему каждому юзеру делать индивидуальный часовой пояс неправильно, а он должен быть на компанию, или как минимум на офис или склад.
использовать исключительно цифры в названиях таблиц и полейЭто 1С.
Соболезную.
Кстати не так давно довелось увидеть базу 1С, у них реально схожее решение с моим, только идентификаторы более навороченные в таблицах и полях (со всякими буквенными приставками типа _Fld8005_RTRef) и служебные поля естественно другие. У меня они числовые в целом. Где там у них конфиги всего этого хранятся я сходу тогда не понял, надо почитать как-нибудь.
Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Тоже сразу об этом подумалось, когда дочитал до трех таблиц и т.д.
А какое ваше решение по очистке базы? Предложите проще.
Не хранить логику в БД, а писать ее на внешнем языке программирования. Банально делаем второе подключение к отдельной базе, и в процедурах изменения данных вызываем что-то типа
$db_log->insert('log_table', [$transaction_id, json_encode($data)])И как вы изменения данных по цепочке триггеров будите логировать?
Например пользователь из интерфейса нажимает на кнопку, которая запускает процедуру в БД, в этой процедуре выполняется добавление-изменение данных в 10 таблицах, в 5 из этих таблиц еще срабатывают триггеры, которые меняют данные еще в каких-то таблицах.
И что за логи вы запишите из интерфейса?
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 дергается такая-то процедура, в 12.30 другая, а в 15.00 третья. Дергается все это универсальным скриптом, который просто по времени дергает те или иные процедуры (какие пользователь укажет) в которых может меняться неизвестное количество данных в нескольких таблицах. Как в этом случае собираетесь из внешнего скрипта логировать изменения?
Например пользователь из интерфейса нажимает на кнопку, которая запускает процедуру в БД, в этой процедуре выполняется добавление-изменение данных в 10 таблицах, в 5 из этих таблиц еще срабатывают триггеры, которые меняют данные еще в каких-то таблицах.
И что за логи вы запишите из интерфейса?
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 дергается такая-то процедура, в 12.30 другая, а в 15.00 третья. Дергается все это универсальным скриптом, который просто по времени дергает те или иные процедуры (какие пользователь укажет) в которых может меняться неизвестное количество данных в нескольких таблицах. Как в этом случае собираетесь из внешнего скрипта логировать изменения?
Триггеры и процедуры в БД — это «логика в БД». Я написал о том, что делать так не надо. Логику лучше делать внутри приложения.
Например пользователь из интерфейса нажимает на кнопку, которая запускает метод объекта на PHP, в этом методе выполняется вызов методов бизнес-логики на добавление-изменение данных в 10 сущностях, в 5 из этих сущностей еще вызываются свои методы, которые меняют данные еще в каких-то сущностях. Все изменения сохраняются в рамках одной транзакции.
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 запускается такая-то задача на PHP, в 12.30 другая, а в 15.00 третья. Задачи запускаются универсальным PHP-скриптом, который прописан, например, в кроне, и запускает те задачи, которые указал пользователь. В задачах может меняться любое количество данных, если мы написали в коде логирование при изменениях, то оно и будет выполняться.
Например пользователь из интерфейса нажимает на кнопку, которая запускает метод объекта на PHP, в этом методе выполняется вызов методов бизнес-логики на добавление-изменение данных в 10 сущностях, в 5 из этих сущностей еще вызываются свои методы, которые меняют данные еще в каких-то сущностях. Все изменения сохраняются в рамках одной транзакции.
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 запускается такая-то задача на PHP, в 12.30 другая, а в 15.00 третья. Задачи запускаются универсальным PHP-скриптом, который прописан, например, в кроне, и запускает те задачи, которые указал пользователь. В задачах может меняться любое количество данных, если мы написали в коде логирование при изменениях, то оно и будет выполняться.
Ну на мой взгляд это как раз овер-инженеринг :) но как говорится каждому свое. Я в большей степени все таки по БД специализируюсь чем по вебу. Поэтому больше решений в структуре БД.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам. Натворить делов могут. Думаю с точки зрения облачной платформы доступной всем — такой подход неприемлем.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам. Натворить делов могут. Думаю с точки зрения облачной платформы доступной всем — такой подход неприемлем.
Я в большей степени все таки по БД специализируюсь чем по вебу. Поэтому больше решений в структуре БД.
Это не значит, что они правильные — это значит, что вы натягиваете решения в зону своей экспертизы.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам.
А что, создание задач в БД чем-то отличается?
Это не значит, что они правильные — это значит, что вы натягиваете решения в зону своей экспертизы.
Статья извиняюсь про БД и в разделе БД.
А что, создание задач в БД чем-то отличается?
По безопасности конечно отличается. В БД по сути только исключать вопросы sql-иньекций и бесконечных циклов. Изолировать возможность деятельности только конкретной базой.
А давать программировать на php неизвестному юзеру на вашем сервере — ну наверное возможно, но в весьма урезанной версии, исключить опасные команды, в общем это намного сложнее на мой взгляд проконтролировать.
Статья извиняюсь про БД и в разделе БД.
… это не значит, что все решения в БД оправданы.
В БД по сути только исключать вопросы sql-иньекций и бесконечных циклов. Изолировать возможность деятельности только конкретной базой.
Отправка почты? Вызов веб-сервисов? Криптография? Это совершенно типовые задачи в ERP-системе.
А давать программировать на php неизвестному юзеру на вашем сервере
А не надо давать PHP, надо давать DSL в песочнице.
Хм, причем здесь «программировать на PHP»? Как я понял, у вас пользователь тоже не на SQL программирует, а использует какой-то 1С-подобный язык, который обрабатывается через интерпретатор на PHP. Я имел в виду примерно то же самое, только интерпретатор не транслирует все в БД, а вызывает процедуры, написанные (вами) на PHP.
Нет. Совершенно не так. Есть 2 части:
1. Пользователь у меня может полностью программировать структуру БД, создавать таблицы, делать процедуры, триггеры. Абсолютно любой сложности и вложенности. Здесь по сути SQL — только не совсем, логика таже, но реализовано это через веб при помощи постройки определенных элементов. SQL запросов (в вашем понимании, как текст) тут нет. Выглядит примерно так, но тут очень простой пример. Более сложное просто в принтскрин не влезет. Поддерживаются любые структуры и компануются они в древовидную структуру определенной последовательность выполнения. Потом идет процесс компилирования — в БД создается нужная процедура из этого.
2. Пользователь может произвольно редактировать веб интерфейс, выводить в элементы интерфейса данные из своих процедур, создавать элементы управления, связывать эти элементы с конкретными процедурами в БД. И т.д. Тут двумя словами не описать. Но тут все делается исключительно редактором при помощи кнопочек, никакого произвольного php текста.
У меня есть справка, Часть 3 и 4 посмотрите если интересно. Но я пока по программированию далеко не все описал. Описана только частично программирование в БД, к описанию веба я пока не приступал. Только оглавление. Думаю в течении 2-3 недель будет описание полное. Пока работаю еще над этим. Очень много работы помимо этого.
1. Пользователь у меня может полностью программировать структуру БД, создавать таблицы, делать процедуры, триггеры. Абсолютно любой сложности и вложенности. Здесь по сути SQL — только не совсем, логика таже, но реализовано это через веб при помощи постройки определенных элементов. SQL запросов (в вашем понимании, как текст) тут нет. Выглядит примерно так, но тут очень простой пример. Более сложное просто в принтскрин не влезет. Поддерживаются любые структуры и компануются они в древовидную структуру определенной последовательность выполнения. Потом идет процесс компилирования — в БД создается нужная процедура из этого.
2. Пользователь может произвольно редактировать веб интерфейс, выводить в элементы интерфейса данные из своих процедур, создавать элементы управления, связывать эти элементы с конкретными процедурами в БД. И т.д. Тут двумя словами не описать. Но тут все делается исключительно редактором при помощи кнопочек, никакого произвольного php текста.
У меня есть справка, Часть 3 и 4 посмотрите если интересно. Но я пока по программированию далеко не все описал. Описана только частично программирование в БД, к описанию веба я пока не приступал. Только оглавление. Думаю в течении 2-3 недель будет описание полное. Пока работаю еще над этим. Очень много работы помимо этого.
Потом идет процесс компилирования — в БД создается нужная процедура из этого.
Ну вот на этом этапе надо создавать не процедуру в БД, а код на аппликейшн-сервере. И все будет хорошо.
Собственно, это и есть DSL, просто визуальный. Лет десять назад они были в моде, как сейчас — не знаю.
PS Я пять, что ли, лет имел дело с прикладной системой такого же генезиса. В поддержке она была отвратительна до невозможности.
А по конкретнее можете описать, что было отвратительного? Мне просто действительно интересно.
И что за система? Я кроме 1С с подобной концепцией никого не знаю. А тем более с реализацией через веб.
И что за система? Я кроме 1С с подобной концепцией никого не знаю. А тем более с реализацией через веб.
А по конкретнее можете описать, что было отвратительного?
Отсутствие всего стандартного инструментария для разработки. Версионное хранилище? Рефакторинг? Тесты? Не, ни шанса.
lair — тут нет требования к проф среде разработки. Главное предназначение этого механизма — корректировки нюансов. Он дает пользователям потрясающую гибкость.
Все пытаются сделать системы, чтобы ее структура подходила всем компаниям, а такого не бывает. У каждой компании свой уникальный бизнес-процесс. Можно сделать что-то среднее — подходящее примерно всем, но как известно — дьявол кроется в нюансах. Нюансы бизнес-процессов копании никогда не угадаете. Но используя такие средства редактирования можно их довольно просто реализовать.
Вресионное хранилище кстати в разработке. Скоро появятся снапшеты процедур, информация о поддерживаемой версии процедуры для централизованного обновления, и собственно сам механизм централизованного обновления.
Тесты — есть система запуска процедуры и просмотра предварительного результата. Для запросов работает очень удобно. Для отладки добавления или удаления данных такое подходит не очень, согласен. Но этого как правило не требуется, я пока не сталкивался чтобы это понадобилось.
Вообще добавления и редактирования давно с нуля не делал чтобы отлаживать. У меня есть очень удобный механизм созадния типовых процедур мегаупрощающий разработку. После создания таблицы можно просто нажать кнопочку «Создать типовые процедуры» и система создаст 5 процедур к этой таблице: Вывод всех данных, Вывод строки, Редактирование строки, Добавление строки, Удаление строки. Там уже будут прописаны все переменные вашей таблицы, весь функционал. Во многих случаях этого даже достаточно. Если требуется что-то немного другое, какие-то фильтры, просто процедура нужная доредактируется. Это намного быстрее и проще.
Можно в процедуру импортировать все переменные с набором из таблицы, можно заполнить вывод селекта по сопоставлению имен переменных.
В общем на самом деле разрабатывать тут гораздо быстрее чем в IBExperte. В нем чтобы сделать процедуру к таблице: давай прописывать переменные и типы данных их на вход-выход, потом перечислять их в select, потом пречислять их в into. На это пипец времени уходит впустую. Я уже забыл что это такое. У меня бывает что целый небольшой модуль в течении часа появляется.
Все пытаются сделать системы, чтобы ее структура подходила всем компаниям, а такого не бывает. У каждой компании свой уникальный бизнес-процесс. Можно сделать что-то среднее — подходящее примерно всем, но как известно — дьявол кроется в нюансах. Нюансы бизнес-процессов копании никогда не угадаете. Но используя такие средства редактирования можно их довольно просто реализовать.
Вресионное хранилище кстати в разработке. Скоро появятся снапшеты процедур, информация о поддерживаемой версии процедуры для централизованного обновления, и собственно сам механизм централизованного обновления.
Тесты — есть система запуска процедуры и просмотра предварительного результата. Для запросов работает очень удобно. Для отладки добавления или удаления данных такое подходит не очень, согласен. Но этого как правило не требуется, я пока не сталкивался чтобы это понадобилось.
Вообще добавления и редактирования давно с нуля не делал чтобы отлаживать. У меня есть очень удобный механизм созадния типовых процедур мегаупрощающий разработку. После создания таблицы можно просто нажать кнопочку «Создать типовые процедуры» и система создаст 5 процедур к этой таблице: Вывод всех данных, Вывод строки, Редактирование строки, Добавление строки, Удаление строки. Там уже будут прописаны все переменные вашей таблицы, весь функционал. Во многих случаях этого даже достаточно. Если требуется что-то немного другое, какие-то фильтры, просто процедура нужная доредактируется. Это намного быстрее и проще.
Можно в процедуру импортировать все переменные с набором из таблицы, можно заполнить вывод селекта по сопоставлению имен переменных.
В общем на самом деле разрабатывать тут гораздо быстрее чем в IBExperte. В нем чтобы сделать процедуру к таблице: давай прописывать переменные и типы данных их на вход-выход, потом перечислять их в select, потом пречислять их в into. На это пипец времени уходит впустую. Я уже забыл что это такое. У меня бывает что целый небольшой модуль в течении часа появляется.
тут нет требования к проф среде разработки.
Вот и люди, которые ту систему писали, так думали.
Но используя такие средства редактирования можно их довольно просто реализовать.
… а можно использовать другие средства редактирования, поддерживающие "профессиональную среду разработки", и все равно реализовать нужные бизнес-процессы.
Вресионное хранилище кстати в разработке.
Вот-вот. Вместо того, чтобы использовать любое мейнстримное, вы разрабатываете свое. Я даже стесняюсь спрашивать про диф/мерж.
Тесты — есть система запуска процедуры и просмотра предварительного результата. Для запросов работает очень удобно.
Это вообще не имеет отношения к тестам.
Вообще добавления и редактирования давно с нуля не делал чтобы отлаживать.
CRUD — это самая тривиальная часть в любом бизнесе, и приличная современная система уже давно генерит CRUD-интерфейс просто по описанию схемы данных.
Цирк начинается, когда заходит речь собственно о бизнес-процессе: это вычисляется так-то, здесь такие-то условия, здесь должно пойти вот так и вот так.
Я не предлагаю никакого произвольного php текста. Все то же самое, как у вас, только вместо процесса компилирования в процедуру БД будет процесс интерпретации интерпретатором. Например, при обработке [:current_timestamp] будет вызов date('Y-m-d H:i:s'). Как вариант, можно сделать компиляцию в PHP код, как это делают шаблонизаторы наподобие Twig. Суть не в том, как это реализовать, а в том, что в этом случае логирование изменений в другой БД становится простой задачей, не требующей добавления триггеров в каждую таблицу.
Ну на мой взгляд разработать такую систему для того чтобы логировать более просто — весьма непросто. Проще уж 3 таблички в БД создать :)
Но вы правы, теоретически ваша версия имеет право на жизнь. Просто получится альтернативная технологическая платформа.
Но что из этого «овер-инженеринг» большой вопрос :)
Но вы правы, теоретически ваша версия имеет право на жизнь. Просто получится альтернативная технологическая платформа.
Но что из этого «овер-инженеринг» большой вопрос :)
не понимаю в чем у вас проблема. Я пишу не про свою платформу, а про техническую часть, как можно реализовать те или иные вещи.В этом и проблема, что пишете. И отнюдь не у меня.
Вы путаете UTC с трамвайной ручкой, а пишете поучительные статьи про работу со временем. И даже не понимаете, что там не мнения, а указание на принципиальные ошибки не просто в вашем способе, а даже в вашем понимании основ темы.
upd з.ы. А на свою «платформу» вы ссылку таки оставили, только что заметил (что, кстати, запрещено правилами, имнип). Даже не сомневался, что там увижу charset=windows-1251, вёрстку таблицами и прочие body bgcolor. Цикл статей про веб-разработку будет? Ой всё, на ночь одни расстройства.
barker — такова политика, минимум css и java. Только по большой необходимости.
OMG! Автор. Вы даже меня заставили вылезти из read-only :)
Какая еще у вас там Java? Может все таки Javascript? Или вы там Java-аплеты имели в виду, которые уже deprecated?
Ну и все таки да. Прочитав ваши статьи, чувствуется что вам не хватает фундаментальных знаний что ли. Про UTC вам верно сказали. Если вы пишете приложение, которое работает в нескольких тайм-зонах, то использовать UTC необходимо. То что вы советуете это скорее анти-паттерн. Вот начитаются новички ваших статей и напишут такое же. А потом поймут все, и будут вспоминать вас недобрым словом :)
такова политика, минимум css и java
Какая еще у вас там Java? Может все таки Javascript? Или вы там Java-аплеты имели в виду, которые уже deprecated?
Ну и все таки да. Прочитав ваши статьи, чувствуется что вам не хватает фундаментальных знаний что ли. Про UTC вам верно сказали. Если вы пишете приложение, которое работает в нескольких тайм-зонах, то использовать UTC необходимо. То что вы советуете это скорее анти-паттерн. Вот начитаются новички ваших статей и напишут такое же. А потом поймут все, и будут вспоминать вас недобрым словом :)
Ну вообще как-то мы очень далеко вылезли из темы статьи. Предлагаю все таки вернуться. Мы рассматриваем темы базы данных, а не веб интерфейсов :)
Javascript имелся ввиду.
Я объясню свою позицию по данному вопросу если очень интересно.
Например у меня в бразуере стоит NoScript, и когда я захожу на какой-то сайт, естественно скрипты не запускаются. И вот знаете, очень печально зачастую все выглядит, хорошо если хоть что-то отображается хоть и криво косо, зачастую вообще просто белая страница и понять что там вообще невозможно.
Я считаю что сайт должен без javascript полностью сохранять свою функциональность, ничего не должно наезжать друг на друга или не отображаться если скрипты в браузере отключены. Скрипты должны только дополнять красивости и плюшечки без которых можно обойтись. Сделать сайт полностью на javascript — ну на мой взгляд это просто дурной тон (простите меня специалисты по java, я против вас как специалистов ничего не имею, но вот реально очень печально такие сайты выглядят).
Про часовые пояса — я не вижу смысла комментировать. По моему уже все сказано. Да и из другой статьи это. Предлагаю все таки там это обсуждать.
С какими-то высказываниями я согласен, все доводы я услышал и выводы сделаны, и я действительно в последующей разработке буду кое что новое учитывать, но повторюсь, нельзя в лоб давать каждому пользователю менять свой часовой пояс, только компания целиком или дробить до офиса или склада — иначе будет белеберда в работе т.к. есть рабочие группы, есть много других нюансов. А в рамках темы статьи, как сделать именно на базы в рамках одного сервера запись в разной временной зоны — на мой взгляд нет решения проще.
Почему люди негативно это восприняли — ну странно на самом деле. Хотя за некоторые конструктивные комментари — спасибо. Лично я посмотрел на проблему немного с другой стороны.
Javascript имелся ввиду.
Я объясню свою позицию по данному вопросу если очень интересно.
Например у меня в бразуере стоит NoScript, и когда я захожу на какой-то сайт, естественно скрипты не запускаются. И вот знаете, очень печально зачастую все выглядит, хорошо если хоть что-то отображается хоть и криво косо, зачастую вообще просто белая страница и понять что там вообще невозможно.
Я считаю что сайт должен без javascript полностью сохранять свою функциональность, ничего не должно наезжать друг на друга или не отображаться если скрипты в браузере отключены. Скрипты должны только дополнять красивости и плюшечки без которых можно обойтись. Сделать сайт полностью на javascript — ну на мой взгляд это просто дурной тон (простите меня специалисты по java, я против вас как специалистов ничего не имею, но вот реально очень печально такие сайты выглядят).
Про часовые пояса — я не вижу смысла комментировать. По моему уже все сказано. Да и из другой статьи это. Предлагаю все таки там это обсуждать.
С какими-то высказываниями я согласен, все доводы я услышал и выводы сделаны, и я действительно в последующей разработке буду кое что новое учитывать, но повторюсь, нельзя в лоб давать каждому пользователю менять свой часовой пояс, только компания целиком или дробить до офиса или склада — иначе будет белеберда в работе т.к. есть рабочие группы, есть много других нюансов. А в рамках темы статьи, как сделать именно на базы в рамках одного сервера запись в разной временной зоны — на мой взгляд нет решения проще.
Почему люди негативно это восприняли — ну странно на самом деле. Хотя за некоторые конструктивные комментари — спасибо. Лично я посмотрел на проблему немного с другой стороны.
«LOG_PACET», «SCRAM» и «SCRUM» путаются на сайте, «NUM_POLE», «API» среднего рода на сайте…
Попахивает дельфями образца середины девяностых
Попахивает дельфями образца середины девяностых
У Oracle для этого есть RAC, распределённые транзакции и DBMS_AQ в зависимости от того, какой результат вам нужен.
Зато Firebird бесплатный.
Зато Firebird бесплатный.
>>Есть более быстрая и лучшая процедура DROP TABLE.
по поводу firebird не скажу, у MS SQL, в описанном случае, для того чтобы быстро очистить таблицу лучше использовать операцию TRUNCATE TABLE, она это делает быстрее, правда есть некоторые ограничения на использования, например таблица не должна содержать внешних ключей для других таблиц.
по поводу firebird не скажу, у MS SQL, в описанном случае, для того чтобы быстро очистить таблицу лучше использовать операцию TRUNCATE TABLE, она это делает быстрее, правда есть некоторые ограничения на использования, например таблица не должна содержать внешних ключей для других таблиц.
Имя поля
доставляет.
Не уверен как в Firebird, а в MySQL я бы попробовал писать логи в черную дыру и настроить репликацию таблицы с логами. В Firebird есть репликация?
ZAPIS SMALLINT,
доставляет.
Не уверен как в Firebird, а в MySQL я бы попробовал писать логи в черную дыру и настроить репликацию таблицы с логами. В Firebird есть репликация?
Я пример писал, вы можете обозвать как угодно.
Штатной репликации в файрберде нет. Есть программы с реализацией репликации. У этих ребят вроде есть насколько я знаю http://www.ibase.ru/hqbird/
Штатной репликации в файрберде нет. Есть программы с реализацией репликации. У этих ребят вроде есть насколько я знаю http://www.ibase.ru/hqbird/
За 6 лет много воды утекло, но не могу удержаться от комментария :)
Формулировка задачи следующая: необходимо писать подробные логи изменений данных пользователями в базе данных (insert, update, delete), но при этом писать их в другой базе данных на другом сервере.
Формулировка неправильная. Статья про другое. Лог пишется не во внешнюю а в в основную базу, речь про то как лог из основной базы переносить в другую.
Рецепт дается такой - откажемся от неэффективного при больших объемах удаления delete from table в пользу drop table/create table и какими хаками обойти связанные с этим ограничения.
Я бы делал иначе.
Выгрузили пакет - загрузили во внешней базе - удалили в базе источнике - собрали мусор.
Удаление и сборка мусора делается так:
delete from log where (id_packet = :id_packet);
commit;
select count(*) from log where (id_packet = :id_packet);
commit;
Пакет данных удалили, мусор после него собрали. Освободившееся в базе место будет использовано сервером.
Проблема описанная в статье у КДВ - это не проблема удаления записей а проблема удаления БОЛЬШОГО КОЛИЧЕСТВА записей. Что бы избежать этой проблемы нужно просто уменьшить количество удаляемых за один раз записей, уменьшением пакета. Это конечно все равно будет медленнее чем drop table зато не так радикально извратно :)
Sign up to leave a comment.
Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных