В продолжении темы 'Вопросы по серверам: очередь команд, вывод' , так как разговор
пошел о сериализации и СУБД...
Итак...
Дворак писал(а):
KadVar писал(а):
А эээ... если уж так хочется, то что мешает использовать СУБД с транзакциями и закрывать их в гарантированно стабильных состояниях ? Я долго все это жевал... кругами.... и к окончательному решению увы не пришел. Есть масса аргументов ЗА использование СУБД, и несколько против.... в частности - она ломается вся целиком, а 24х365 админа у нас нету, увы... нереально это. Что делать - неясно.
Я тоже долго ходил вокруг СУБД. И решил отказаться по разным причинам, в том числе и те, которые привел ты - ломается целиком, пришлось бы зависить от стороннего ПО, не факт что было бы быстрее собственного решения, сложнорасширяемое решение. При развитии движка пришлось бы городить новые таблицы и менять старые. СУБД рулит при сложных взаимосвязях, а в маде связи наооборот простые... список мобов, объектов, чаров, где находяться и что имеют...
это все... СУБД получался для меня слишком избыточным. Поэтому перешел к простому дампу мира - в постраничном файле, где мир пишется в бинарном формате. Этот дамп требуется только в случае сбоя в работе... При нормальном завершении - вся информация сохраняется в хмл, а дамп файл удаляется.
KadVar писал(а):
В принципе не вижу никаких проблем, кроме проблем с поддержкой.
С другой стороны... сломается и хрен с ним, пусть ломается. Утром приду и исправлю.
Это лучше, чем если будет потихоньку ломаться.... в процессе работы.
Основные плюсы - транзакции. Основные минусы - большая привязка к хостингу итп.
Скорость... трудно сказать, не думаю, что самописное будет заметно быстрее.
С другой стороны... сломается и хрен с ним, пусть ломается. Утром приду и исправлю.
Это лучше, чем если будет потихоньку ломаться.... в процессе работы.
Основные плюсы - транзакции. Основные минусы - большая привязка к хостингу итп.
Скорость... трудно сказать, не думаю, что самописное будет заметно быстрее.
Не буду привязываться к словам, СУБД хороший вариант, но я взял и плюсы и минусы
вариантов с СУБД или без и вот что получилось:
Плюсы СУБД : Транзакции, т.е гарантированность корректности данных, при условии, что код
программы написан правильно и не будет левых запросов, достаточная простота реализации,
хотя это зависит от языка программирования, прекрасная скорость работы.
Минусы : зависимость от чужого ПО, необходимость его устанавливать, настраивать и поддерживать.
Если база портится, то она портится целиком.
Плюсы варианта без СУБД : достаточная простота реализации - сериализация в поток это стандартная задача
в программировании. Отличная скорость работы (запись потока идет чуть быстрее чем запись в БД, хотя это некритично).
Нет зависимости от стороннего ПО. Нет необходимости в поддержке этого ПО.
Минусы : нет транзакций, что означает вероятность повредить данные, в случае сбоя или неправильного кода.
Сложную расширяемость и совместимость из-за отсутствия унификации хранения данных в потоке, невозможность поддержки.
Я выбрал средний вариант стандартной сериализации с транзакциями. Это дает вариант скорости с надежностью.
В качестве уникации хранения данных я использую xml. В процессе работы используется оба варианта - для
большей части данных, которые часто меняются - сериализация, для меньшей - xml. При остановке сервера -
все данные сохраняются в xml, а файл сериализации стирается за ненадобностью. В случае проблемы,
остаются данные в файле сериализации. При необходимости - запускается движок, он читает сериализованные данные
и сохраняет их в xml. Так я побеждаю проблему с совместимости сериализованных данных.
KadVar писал(а):
С другой стороны... сломается и хрен с ним, пусть ломается. Утром приду и исправлю.
Это лучше, чем если будет потихоньку ломаться.... в процессе работы.
Это лучше, чем если будет потихоньку ломаться.... в процессе работы.
Ломаться в процессе работы потихоньку... это как ?
А на счет поломки БД ... тут уж я все же думаю, что проблема решаема...
Как это получится у меня, покажет время