Кстати про триггеры. А если на каждую таблицу создать триггеры. Как было сказано выше - удалений в базе не бывает, тогда получается по 2 триггера на таблицу (INSERT, UPDATE). При срабатывании триггера новые/измененные данные пишем в отдельную таблицу, потом через определенный промежуток времени забираем данные из этой таблицы и рассылаем, таблицу чистим. Или можно также создать для каждой таблицы другую с такой же структурой. И тогда придется не из одной таблицы данные собирать, а из всех.
Что с ладж обжектами делать, им же ID автоматически присваивается. К пример на сервере дирекции создали Документ и прикрепили к нему скан. В базе создастся один ладж обжект LOID= 987654321 и несколько строк в таблицах, причем в двух строках в столбцах будет записан LOID. Теперь предположим я делаю синхронизацию и новые строки разлетаются из дирекции по всем филиалам. А как туда передать ладж обжект, да так чтобы еще и LOID у него стал как в дирекции?
да и литературы и доков пока маловато, кажется. я решил подождать пока хоть один человек напишет, что я на ней что-то сделал. так то и так то хорошо, тут-то и там-то плохо
Ну, когда я в прошлом году на конференции RuPyRu был, там чувак про нее вроде рассказывал, как она применилась в рабочем проекте. Но к сожалению, я слушал в это время доклад в другом потоке и успел только к концу.
Зачем, если можно просто помечать измененные данные флагом (отдельное поле) Ну, во-первых, а зачем должен быть тот же id? Это и есть плюс своего софта - можно поменять его и поменять в записи. А во-вторых, уверены что вообще large objects нужны?
по StrokeDB все очень плохо выглядит. Сайт их закрыт. Исходники в репозитарии целый год уже не обновлялись. И гугл тоже молчит. Что то невнятное выдает. Какие-то обрывки в основном про ту самую конференцию. Похоже, что Строук накрылся медным тазом...
А почему нет? Это внутренний ID базы, который нигде "снаружи" не выбирается, а является лишь ссылкой, которая лежит в таблице. Вас же не удивит, что скопировав файл с сервера на сервер - у этих файлов могут быть разные inode? Нет, это нормально, ибо все-равно вы работаете не с inode-ами, а с именем файла, который есть указатель. Так же будет и с большими объектами. Да и потом, при создании больших объектов вы можете сами oid назначить - вот и делайте это руками с шагом - как и с инкрементами.
А в чем смысл PDO, если там большие объекты - все равно кастомное решение для постгреса не совместимое с другими базами? Во встроенном PHP драйвере вроде есть такое, в PDO вроде как нет.
да оно и без больших объектов было бы таким же кастомным. По SQL-ю все равно не совместимо с другими базами. все равно смысл в PDO есть, потому что удобный интерфейс и умеет работать со всеми базами через один интерфейс. Это реально очень полезное свойство, очень сильно выручило меня когда я переходил с MySQL на Postgres. Ну и объекты опять же. Исключения. От PDO- то я никуда не уйду. Это факт. А вот с репликацией больших объектов пока что затык. Завтра еще подумаем.
Если начать изучение SQL не с старинных книжек по MySQL и хотя бы немного смотреть на стандарты - никаких проблем по переходу с мускуля на постгрес нет. А те костыли, которые там есть (и которые, как правило, просто от неграмотно построенных запросов, которые мускуль ест, а постгрес - нет) - от них PDO не спасет. Конечно, если есть абстракиция ДБ в софте. В общем, переводил не одну систему с мускуля на постгрес. Вот обратно уже сложнее слезть, хотя бы из-за отсутствия массивов. Потом, у PDO стандартные средства позволяют нормально оперировать большими объектами (теми, что в таблице хранятся), если, конечно, вы не сотнями мегабайт оперируете, я цитату выше приводил из документации - так что постгресовские большие объекты и не понадобятся. А если у вас все же объекты гигабайты весят... мне интересно будет посмотреть, как вы их любым способом реплицировать будете =)
àñèíõðîííàÿ ðåïëèêàöèÿ PostgreSQL Òû âûõîäèøü èç ô-èè ïî òàéìàóòó, ïðè ýòîì îïåðàöèÿ ÷òåíèÿ âñå ðàâíî ïðîäîëæàåòñÿ, çàêîí÷èòüñÿ îíà òîëüêî êîãäà áóäåò ïðî÷èòàíî N áàéò, íî åå ðåçóëüòàò òû ïîëó÷èòü óæå íå ñìîæåøü, âûçûâàé CancelIo. È âîîáùå çà÷åì âñå ýòè àñèíõðîííûå îïåðàöèè, åñëè ó òåáÿ âûïîëíåíèå áëîêèðóåòñÿ íà êàêîå-òî âðåìÿ, òî æå ñàìîå ìîæíî ñäåëàòü è íå èñïîëüçóÿ overlapped.