Защита целосности и структуры данных DB

[ALF.]

Вот и пришел день, когда я задал себе вопрос: "Зачем писать 100500 строк кода реализации апдейта изменений в БД, при изменении какой то ключевой записи". На сегодняшний день, я уже знал о релейшнах и триггерах, но руки до реализации связок таблиц так и не дошли...

Какая от этого польза
Возьмем к примеру все таблицы accounts_***
Все таблицы, которые начинаются на accounts_ имеют в себе ключ - который отвечает за логин пользователя (который хранится в таблица accoutns).
Мы можем спроектировать таблицы так, что при удалении или изминении записи в таблице accounts - записи в других таблицах, которые ссылаются на таблицу accouns - будут изменены автоматически.

Для реализации этого используется FOREIGN KEY
Например:

PHP код:

<?php 

CREATE TABLE IF NOT EXISTS `account_log` (

  `time` int(11) NOT NULL,

  `login` varchar(32) NOT NULL,

  `ip` varchar(15) NOT NULL,

  KEY `login` (`login`),

  KEY `ip` (`ip`),

  FOREIGN KEY (`login`) REFERENCES `accounts` (`login`)

    ON UPDATE CASCADE

    ON DELETE CASCADE

) DEFAULT CHARSET=utf8 

[linliss]

Полностью реализовать и "уследить" изменения в самом игровом сервере - хорошо, но часто трудно, а именно трудно найти место где это забыли сделать. Я считаю намного проще реализовать хорошую структуру БД, что даст возможность избежать "косяки, баги, дюпы" и т. д. К примеру - удалился игрок с БД. В таблице чарактерс его нету. Но произошел сбой, и очистка его предметов в таблице итемс не произошла. Без связи БД есть возможность, что зарегистрируется новый игрок, обджектАйди которого совпадет с удаленным - он получит итемы персонажа который был удален. Со связанной структурой БД - такого не получится.

у меня например objectId используется только для обьектов в сервере, в бд его вообще нету и ненужно такой велосипед городить(если что-то и не удалится из таблиц, то это произойдет при следующем старте кешед сервера, и получить данные другого обьекта "случайно" нереально)

[ALF.]

у меня например objectId используется только для обьектов в сервере, в бд его вообще нету и ненужно такой велосипед городить(если что-то и не удалится из таблицы, то это произойдет при следующем старде кешед сервера, и получить данные другого обьекта "случайно" нереально)

Согласен, это было бы тру, но почти полностью перепиливать сервер сайд л2 - нету времени)

[Lihoy]

Автор, конечно, молодец, что выделил личное время для создания как-никак полезной темы на форуме.

Но, грамотное проектирование БД - прописная истина при разработке серьезных систем и это должен знать каждый. Не связанных таблиц практически быть не должно (конечно, все зависит от отношениями между сущностями).

Но разработчики sf, видимо, не задумывались над этими вещами изначально, а затем эта оплошность, как снежный ком, накапливалась и превратилась в нечто несуразное

[SoniPro]

Спасибо за информацию. Очень интересно.

[KID]

Но разработчики sf, видимо, не задумывались над этими вещами изначально, а затем эта оплошность, как снежный ком, накапливалась и превратилась в нечто несуразное

видимо кто-то не застал времена повеливания csv, а уже потом, кто-то там быстро перешмыгнул на мускул. в попыхах.
они не давали готовый продукт, они давали старт для других.
к сожалению такие нюансы мало кого волнуют, из "одминов" серверов

Я лично использую несколько idfactory

[Visor]

Похвально, что вы узнали о внешних ключах и реляционной модели баз данных.
Я вначале был шокирован набором беспорядочных таблиц - которое для л2 называли разработчики базой данных. Была мысль ее довести до более-менее приемлемой модели. Но кал самого ява-сервера - модели ООП не в дугу, утечки, лаги, все неправильно в предметной области - забрало время. Сейчас не тянет трогать структуру базы л2.
Проектируя сначала - можно было бы конечно сразу делать в какой-то модели ее, а на ходу сильно переделывать - лень.

[ALF.]

п.с. кто так и не понял что должно получится в конце - продемонстрирую структуру БД проекта, над которым я сейчас работаю



п.п.с. надеюсь что в БД своего ГС-а доведу до нормального вида

[acmi]

На протяжении нескольких лет появляются темы типо: го запилим ORM и всякие другие крутые штуки. И каждый раз один и тот же итог: нет времени/нет желания копаться в какахах/куда вы лезете со своим энтерпрайзом. В итоге: мыши плакали, кололись, но продолжали грызть кактус.

Может все-таки стоит нормально работать с данными на уровне приложения, а не бд? Зачем так укреплять зависимость от конкретного хранилища?

[linliss]

Может все-таки стоит нормально работать с данными на уровне приложения, а не бд? Зачем так укреплять зависимость от конкретного хранилища?

и сколько же серверов работает не на mysql?