Комментарии 50
… а в это время другие люди используют Event Sourcing, да.
(или, по крайней мере, очереди событий)
Первое что приходит на ум, это огромнейшая избыточность. Но мне конечно надо переварить такой подход, поэтому пока не берусь что-то говорить по этому поводу. Возможно такой подход в каких-то случаях действительно можно эффективно использовать.
— вы серьёзно?
«Таблиц LOG делается 3 штуки. LOG_1 – в первый день данные пишутся сюда, LOG_2 – в следующий день данные пишутся сюда, и т.д. происходит чередование, один день в LOG_1 второй день в LOG_2.»
— точно серьёзно?
удалите статью пока не поздно.
Запись происходит через раз. В общем запись не гарантирована.Ух, ты!
Похоже, Tortortor выше был прав:
удалите статью пока не поздно.
Вот вам вырезка из мануала по файрберду
Необязательное предложение EXTERNAL [FILE] указывает, что таблица хранится
вне базы данных во внешнем текстовом файле. Столбцы таблицы, хранящейся во
внешнем файле, могут быть любого типа за исключением BLOB и массивов с любым
типом данных. Над таблицей, хранящейся во внешнем файле, допустимы только
операции добавления новых строк (INSERT) и выборки (SELECT) данных. Операции
же изменения существующих данных (UPDATE) или удаления строк такой таблицы
(DELETE) не могут быть выполнены.
Если вы импортируете данные из таблицы запросом, все у вас будет хорошо. А вот когда идет интенсивная запись из триггера например… данные теряются (как я убедился). Я долго не мог понять что же за чудеса творятся, запись может произойти, а может и не произойти. Можете самостоятельно провести данные эксперименты. (я правда на firebirde 2.5 еще их проводил, но в третем думаю с этим ничего не изменилось)
Внешние таблицы хороши для переноса больших массивов информации из одной БД в другую. Тут у вас все получится. Использовать же их в онлайне — терять данные.
Плюс отмечу, что для данной задачи подход через внешние таблицы не подходит, ибо в них нельзя blob поля записывать, а сделать одну таблицу под все свои данные не получится ибо надо заранее знать их формат. Вы не можете сделать мегавнешнюю таблицу под все свои данные, тем более что пользователь может, у меня в частности, придумывать еще и свои. Кроме блоба тут ничего не подойдет.
Так же я приветствую конструктивную критику.По-моему, это всё же тупо троллинг.
Итак, в предыдущей статье про «облачную платформу для автоматизации предприятий», «неограниченно масштабируемую, с огромным числом потенциальных пользователей» и про работу со временем выяснилось, что вы не только совершенно неприемлемо это делаете и даже не понимаете почему так делать нельзя (о чём вам сказали ВСЕ комментаторы), но и даже не понимаете что такое UTC (!!!).
И вы всё же продолжаете «цикл статей»? Это не шутка?
Конструктивную критику я приветствую, потому что это дает возможность взглянуть на проблемы под другим углом и это действительно полезно. Никакого троллинга тут нет. Я вполне серьезно это написал.
И главное, что пугает — это уже кем-то реализовано на практике.
Основная проблема по статье с часовыми поясами:
UTC — не должен зависеть от часового пояса, локальное время — должно. Смешивая эти два понятия Вы выносите мозги вообще всем.
Проблемы в данном случае:
Манипуляция с тремя таблицами и дополнительными вьюшками… Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Что-то мне подсказывает, что использовать исключительно цифры в названиях таблиц и полей — не очень-то и здоровая идея, которая безумно усложняет поддержку.
«свой встроенный язык программирования в систему» — учитывая всё прочитанное, извините, очень страшно, но безумно интересно увидеть его описание.
LOG_PACET — граммарнаци негодуют (А гугл транслейт распознаёт это как индонезийский и подсказывает перевод — «слизни»)
Давайте споры по поводу UTC перенесем в ту статью. Я никому мозг не выношу, я описал конкретный способ который работает и обосновал почему каждому юзеру делать индивидуальный часовой пояс неправильно, а он должен быть на компанию, или как минимум на офис или склад.
использовать исключительно цифры в названиях таблиц и полейЭто 1С.
Извините, слегка овер-инжиниринг на пустом месте, для выгрузки данных из базы.
Тоже сразу об этом подумалось, когда дочитал до трех таблиц и т.д.
$db_log->insert('log_table', [$transaction_id, json_encode($data)])
Например пользователь из интерфейса нажимает на кнопку, которая запускает процедуру в БД, в этой процедуре выполняется добавление-изменение данных в 10 таблицах, в 5 из этих таблиц еще срабатывают триггеры, которые меняют данные еще в каких-то таблицах.
И что за логи вы запишите из интерфейса?
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 дергается такая-то процедура, в 12.30 другая, а в 15.00 третья. Дергается все это универсальным скриптом, который просто по времени дергает те или иные процедуры (какие пользователь укажет) в которых может меняться неизвестное количество данных в нескольких таблицах. Как в этом случае собираетесь из внешнего скрипта логировать изменения?
Например пользователь из интерфейса нажимает на кнопку, которая запускает метод объекта на PHP, в этом методе выполняется вызов методов бизнес-логики на добавление-изменение данных в 10 сущностях, в 5 из этих сущностей еще вызываются свои методы, которые меняют данные еще в каких-то сущностях. Все изменения сохраняются в рамках одной транзакции.
Или еще интереснее, у пользователя настроен план автоматических действий, в 10.00 запускается такая-то задача на PHP, в 12.30 другая, а в 15.00 третья. Задачи запускаются универсальным PHP-скриптом, который прописан, например, в кроне, и запускает те задачи, которые указал пользователь. В задачах может меняться любое количество данных, если мы написали в коде логирование при изменениях, то оно и будет выполняться.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам. Натворить делов могут. Думаю с точки зрения облачной платформы доступной всем — такой подход неприемлем.
Я в большей степени все таки по БД специализируюсь чем по вебу. Поэтому больше решений в структуре БД.
Это не значит, что они правильные — это значит, что вы натягиваете решения в зону своей экспертизы.
Как кстати у вас пользователь будет создавать эти задачи на php из своего интерфейса? Мне кажется как минимум с точки зрения безопасности нельзя давать таких вещей неизвестным юзерам.
А что, создание задач в БД чем-то отличается?
Это не значит, что они правильные — это значит, что вы натягиваете решения в зону своей экспертизы.
Статья извиняюсь про БД и в разделе БД.
А что, создание задач в БД чем-то отличается?
По безопасности конечно отличается. В БД по сути только исключать вопросы sql-иньекций и бесконечных циклов. Изолировать возможность деятельности только конкретной базой.
А давать программировать на php неизвестному юзеру на вашем сервере — ну наверное возможно, но в весьма урезанной версии, исключить опасные команды, в общем это намного сложнее на мой взгляд проконтролировать.
Статья извиняюсь про БД и в разделе БД.
… это не значит, что все решения в БД оправданы.
В БД по сути только исключать вопросы sql-иньекций и бесконечных циклов. Изолировать возможность деятельности только конкретной базой.
Отправка почты? Вызов веб-сервисов? Криптография? Это совершенно типовые задачи в ERP-системе.
А давать программировать на php неизвестному юзеру на вашем сервере
А не надо давать PHP, надо давать DSL в песочнице.
1. Пользователь у меня может полностью программировать структуру БД, создавать таблицы, делать процедуры, триггеры. Абсолютно любой сложности и вложенности. Здесь по сути SQL — только не совсем, логика таже, но реализовано это через веб при помощи постройки определенных элементов. SQL запросов (в вашем понимании, как текст) тут нет. Выглядит примерно так, но тут очень простой пример. Более сложное просто в принтскрин не влезет. Поддерживаются любые структуры и компануются они в древовидную структуру определенной последовательность выполнения. Потом идет процесс компилирования — в БД создается нужная процедура из этого.
2. Пользователь может произвольно редактировать веб интерфейс, выводить в элементы интерфейса данные из своих процедур, создавать элементы управления, связывать эти элементы с конкретными процедурами в БД. И т.д. Тут двумя словами не описать. Но тут все делается исключительно редактором при помощи кнопочек, никакого произвольного php текста.
У меня есть справка, Часть 3 и 4 посмотрите если интересно. Но я пока по программированию далеко не все описал. Описана только частично программирование в БД, к описанию веба я пока не приступал. Только оглавление. Думаю в течении 2-3 недель будет описание полное. Пока работаю еще над этим. Очень много работы помимо этого.
Потом идет процесс компилирования — в БД создается нужная процедура из этого.
Ну вот на этом этапе надо создавать не процедуру в БД, а код на аппликейшн-сервере. И все будет хорошо.
Собственно, это и есть DSL, просто визуальный. Лет десять назад они были в моде, как сейчас — не знаю.
PS Я пять, что ли, лет имел дело с прикладной системой такого же генезиса. В поддержке она была отвратительна до невозможности.
И что за система? Я кроме 1С с подобной концепцией никого не знаю. А тем более с реализацией через веб.
А по конкретнее можете описать, что было отвратительного?
Отсутствие всего стандартного инструментария для разработки. Версионное хранилище? Рефакторинг? Тесты? Не, ни шанса.
Все пытаются сделать системы, чтобы ее структура подходила всем компаниям, а такого не бывает. У каждой компании свой уникальный бизнес-процесс. Можно сделать что-то среднее — подходящее примерно всем, но как известно — дьявол кроется в нюансах. Нюансы бизнес-процессов копании никогда не угадаете. Но используя такие средства редактирования можно их довольно просто реализовать.
Вресионное хранилище кстати в разработке. Скоро появятся снапшеты процедур, информация о поддерживаемой версии процедуры для централизованного обновления, и собственно сам механизм централизованного обновления.
Тесты — есть система запуска процедуры и просмотра предварительного результата. Для запросов работает очень удобно. Для отладки добавления или удаления данных такое подходит не очень, согласен. Но этого как правило не требуется, я пока не сталкивался чтобы это понадобилось.
Вообще добавления и редактирования давно с нуля не делал чтобы отлаживать. У меня есть очень удобный механизм созадния типовых процедур мегаупрощающий разработку. После создания таблицы можно просто нажать кнопочку «Создать типовые процедуры» и система создаст 5 процедур к этой таблице: Вывод всех данных, Вывод строки, Редактирование строки, Добавление строки, Удаление строки. Там уже будут прописаны все переменные вашей таблицы, весь функционал. Во многих случаях этого даже достаточно. Если требуется что-то немного другое, какие-то фильтры, просто процедура нужная доредактируется. Это намного быстрее и проще.
Можно в процедуру импортировать все переменные с набором из таблицы, можно заполнить вывод селекта по сопоставлению имен переменных.
В общем на самом деле разрабатывать тут гораздо быстрее чем в IBExperte. В нем чтобы сделать процедуру к таблице: давай прописывать переменные и типы данных их на вход-выход, потом перечислять их в select, потом пречислять их в into. На это пипец времени уходит впустую. Я уже забыл что это такое. У меня бывает что целый небольшой модуль в течении часа появляется.
тут нет требования к проф среде разработки.
Вот и люди, которые ту систему писали, так думали.
Но используя такие средства редактирования можно их довольно просто реализовать.
… а можно использовать другие средства редактирования, поддерживающие "профессиональную среду разработки", и все равно реализовать нужные бизнес-процессы.
Вресионное хранилище кстати в разработке.
Вот-вот. Вместо того, чтобы использовать любое мейнстримное, вы разрабатываете свое. Я даже стесняюсь спрашивать про диф/мерж.
Тесты — есть система запуска процедуры и просмотра предварительного результата. Для запросов работает очень удобно.
Это вообще не имеет отношения к тестам.
Вообще добавления и редактирования давно с нуля не делал чтобы отлаживать.
CRUD — это самая тривиальная часть в любом бизнесе, и приличная современная система уже давно генерит CRUD-интерфейс просто по описанию схемы данных.
Цирк начинается, когда заходит речь собственно о бизнес-процессе: это вычисляется так-то, здесь такие-то условия, здесь должно пойти вот так и вот так.
Но вы правы, теоретически ваша версия имеет право на жизнь. Просто получится альтернативная технологическая платформа.
Но что из этого «овер-инженеринг» большой вопрос :)
не понимаю в чем у вас проблема. Я пишу не про свою платформу, а про техническую часть, как можно реализовать те или иные вещи.В этом и проблема, что пишете. И отнюдь не у меня.
Вы путаете UTC с трамвайной ручкой, а пишете поучительные статьи про работу со временем. И даже не понимаете, что там не мнения, а указание на принципиальные ошибки не просто в вашем способе, а даже в вашем понимании основ темы.
upd з.ы. А на свою «платформу» вы ссылку таки оставили, только что заметил (что, кстати, запрещено правилами, имнип). Даже не сомневался, что там увижу charset=windows-1251, вёрстку таблицами и прочие body bgcolor. Цикл статей про веб-разработку будет? Ой всё, на ночь одни расстройства.
такова политика, минимум css и java
Какая еще у вас там Java? Может все таки Javascript? Или вы там Java-аплеты имели в виду, которые уже deprecated?
Ну и все таки да. Прочитав ваши статьи, чувствуется что вам не хватает фундаментальных знаний что ли. Про UTC вам верно сказали. Если вы пишете приложение, которое работает в нескольких тайм-зонах, то использовать UTC необходимо. То что вы советуете это скорее анти-паттерн. Вот начитаются новички ваших статей и напишут такое же. А потом поймут все, и будут вспоминать вас недобрым словом :)
Javascript имелся ввиду.
Я объясню свою позицию по данному вопросу если очень интересно.
Например у меня в бразуере стоит NoScript, и когда я захожу на какой-то сайт, естественно скрипты не запускаются. И вот знаете, очень печально зачастую все выглядит, хорошо если хоть что-то отображается хоть и криво косо, зачастую вообще просто белая страница и понять что там вообще невозможно.
Я считаю что сайт должен без javascript полностью сохранять свою функциональность, ничего не должно наезжать друг на друга или не отображаться если скрипты в браузере отключены. Скрипты должны только дополнять красивости и плюшечки без которых можно обойтись. Сделать сайт полностью на javascript — ну на мой взгляд это просто дурной тон (простите меня специалисты по java, я против вас как специалистов ничего не имею, но вот реально очень печально такие сайты выглядят).
Про часовые пояса — я не вижу смысла комментировать. По моему уже все сказано. Да и из другой статьи это. Предлагаю все таки там это обсуждать.
С какими-то высказываниями я согласен, все доводы я услышал и выводы сделаны, и я действительно в последующей разработке буду кое что новое учитывать, но повторюсь, нельзя в лоб давать каждому пользователю менять свой часовой пояс, только компания целиком или дробить до офиса или склада — иначе будет белеберда в работе т.к. есть рабочие группы, есть много других нюансов. А в рамках темы статьи, как сделать именно на базы в рамках одного сервера запись в разной временной зоны — на мой взгляд нет решения проще.
Почему люди негативно это восприняли — ну странно на самом деле. Хотя за некоторые конструктивные комментари — спасибо. Лично я посмотрел на проблему немного с другой стороны.
Попахивает дельфями образца середины девяностых
Зато Firebird бесплатный.
по поводу firebird не скажу, у MS SQL, в описанном случае, для того чтобы быстро очистить таблицу лучше использовать операцию TRUNCATE TABLE, она это делает быстрее, правда есть некоторые ограничения на использования, например таблица не должна содержать внешних ключей для других таблиц.
ZAPIS SMALLINT,
доставляет.
Не уверен как в Firebird, а в MySQL я бы попробовал писать логи в черную дыру и настроить репликацию таблицы с логами. В Firebird есть репликация?
Штатной репликации в файрберде нет. Есть программы с реализацией репликации. У этих ребят вроде есть насколько я знаю 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 зато не так радикально извратно :)
Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных