Реклама Google — средство выживания форумов :)
Ну как говорится - в семье не без уродаzabbix:да, только idfactory вечно сюрпризы преподносит
awarm:Хотя если требуется вообще уникальный id для каждого объекта... ну тогда ой..
Да нет, не "ой" ж-)Balancer:- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся
awarm:Ну на офе все сделано просто - там за всем сам SQL следит, благо в нем все для этого есть, в отличии от MySQL.
А вообще меня эти ID убивали с самого начала. Для CSV файлов они еще нужны были, а тут... да и сама структура базы дикая
Теперь по сути:
1. Отказываться от цифровых идентификаторов считаю неразумным - очень сильно разрастется объем базы данных.
2. Вместо ручной генерации ID, нужно переходить на identity, с переодичской реорганизацией. Реорганизацию организовать с ручным запуском.
3. Для контроля целостности использовать связи. таким образом, пока на какой-то из объектов будет существовать ссылка, удалить этот объект будет нельзя. использовать это для конроля при удалении записей.
Могу дальше напридумывать много плюсов, хотя минусы тоже есть.
Но плюсов больше.
Я - ЗА.
А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что это не вариант...awarm:а в базе использовать нормальные свои
Serge:А свои это какие? держать bigint-овые поля с autoencrement-ом? сдается мне что это не вариант...awarm:а в базе использовать нормальные свои
Не! Я не об этом! Речь шла о внутриигровых и датабазных идентификаторах (не о привязки чего-либо к чарактеру) с внутриигровыми понятно - простой каунтер на спавн, вопрос какой способ генерации IDшников выбрать для базы... авто-инкрементное поле либо фича а-ля той-же IdFactory. авто-инкремент для таких вещей как-раз предназначен, единственное что настораживает это как-раз процесс "реорганизаци" + "alter table xxx auto_increment=zz" этих ID-шников...awarm:Ты считаешь, что текстовые поля будут лучше???
Balancer:Есть идея по сабжу.
- Отказываемся от хранения цифровых идентификаторов в БД вообще.
Balancer:- Принадлежность вещей, петов и т.п. игрокам прописывается прямо не цифровым индексом, а именем игрока
Balancer:(напомню, имена у нас уникальные, скорость поиска по индексированной строке в mysql не ниже, чем поиск по индексированным числовым значениям).
Balancer:- Идентификаторы кланов задаются также их именами
Balancer:- Идентифиакторы раздаются с минимального значения при каждом старте сервера каждому новому создаваемому объекту и в БД не хранятся
Balancer:Плюсы:
- не будет больше бардака с ID
Balancer:- не потребуется сжатие БД
Balancer:- проще будет работать визуально с БД (скажем, сразу видишь, какому игроку принадлежит предмет)
Balancer:Минусы:
- Усложняется переименование игрока (апдейт всех таблиц) и кланов
- Требуется переписывание структуры нынешних БД
...
Жду отзывов от других разработчиков. Не хотелось бы ради одного этого эксперимента опять "отслаиваться" в L2J Balancer, а внесение столь серьёзной доработки в L2JRU или l2j.sf требует согласования с другими участниками