Защита целосности и структуры данных DB
Вот и пришел день, когда я задал себе вопрос: "Зачем писать 100500 строк кода реализации апдейта изменений в БД, при изменении какой то ключевой записи". На сегодняшний день, я уже знал о релейшнах и триггерах, но руки до реализации связок таблиц так и не дошли...
Какая от этого польза Возьмем к примеру все таблицы accounts_*** Все таблицы, которые начинаются на accounts_ имеют в себе ключ - который отвечает за логин пользователя (который хранится в таблица accoutns). Мы можем спроектировать таблицы так, что при удалении или изминении записи в таблице accounts - записи в других таблицах, которые ссылаются на таблицу accouns - будут изменены автоматически. Для реализации этого используется FOREIGN KEY Например: PHP код:
Ниже я представил 2 изображения структуры моих таблиц. А именно таблицы characters_ без связки и со связкой: Скрин №1 http://screenshot.ru/images/2013/08/19/3FVKD.th.png Скрин №2 http://screenshot.ru/images/2013/08/19/9KkgNta.th.png А вот и моя структура таблиц Логин Сервера http://screenshot.ru/images/2013/08/19/TBEkKGUA.png Вывод: Полностью реализовать и "уследить" изменения в самом игровом сервере - хорошо, но часто трудно, а именно трудно найти место где это забыли сделать. Я считаю намного проще реализовать хорошую структуру БД, что даст возможность избежать "косяки, баги, дюпы" и т. д. К примеру - удалился игрок с БД. В таблице чарактерс его нету. Но произошел сбой, и очистка его предметов в таблице итемс не произошла. Без связи БД есть возможность, что зарегистрируется новый игрок, обджектАйди которого совпадет с удаленным - он получит итемы персонажа который был удален. Со связанной структурой БД - такого не получится. п.с. Я только начал делать структуру.... Если её доделать до конца - связей будет куда больше... Да и запросы можно будет строить куда удобнее.... п.п.с. Интересно, занимался ли еще кто то подобным в сфере л2? Какие результаты? Добавлено через 6 минут UPD: Еще парочка скринов http://screenshot.ru/images/2013/08/19/DNwyqVHAJ.png http://screenshot.ru/images/2013/08/19/ZuQXKheWa.png |
Re: Защита целосности и структуры данных DB
Цитата:
|
Re: Защита целосности и структуры данных DB
Цитата:
|
Re: Защита целосности и структуры данных DB
Автор, конечно, молодец, что выделил личное время для создания как-никак полезной темы на форуме.
Но, грамотное проектирование БД - прописная истина при разработке серьезных систем и это должен знать каждый. Не связанных таблиц практически быть не должно (конечно, все зависит от отношениями между сущностями). Но разработчики sf, видимо, не задумывались над этими вещами изначально, а затем эта оплошность, как снежный ком, накапливалась и превратилась в нечто несуразное :) |
Re: Защита целосности и структуры данных DB
Спасибо за информацию. Очень интересно.
|
Re: Защита целосности и структуры данных DB
Цитата:
они не давали готовый продукт, они давали старт для других. к сожалению такие нюансы мало кого волнуют, из "одминов" серверов Я лично использую несколько idfactory |
Re: Защита целосности и структуры данных DB
Похвально, что вы узнали о внешних ключах и реляционной модели баз данных.
Я вначале был шокирован набором беспорядочных таблиц - которое для л2 называли разработчики базой данных. Была мысль ее довести до более-менее приемлемой модели. Но кал самого ява-сервера - модели ООП не в дугу, утечки, лаги, все неправильно в предметной области - забрало время. Сейчас не тянет трогать структуру базы л2. Проектируя сначала - можно было бы конечно сразу делать в какой-то модели ее, а на ходу сильно переделывать - лень. |
Re: Защита целосности и структуры данных DB
п.с. кто так и не понял что должно получится в конце - продемонстрирую структуру БД проекта, над которым я сейчас работаю
http://screenshot.ru/images/2013/09/06/6pcIj.jpg п.п.с. надеюсь что в БД своего ГС-а доведу до нормального вида |
Re: Защита целосности и структуры данных DB
На протяжении нескольких лет появляются темы типо: го запилим ORM и всякие другие крутые штуки. И каждый раз один и тот же итог: нет времени/нет желания копаться в какахах/куда вы лезете со своим энтерпрайзом. В итоге: мыши плакали, кололись, но продолжали грызть кактус.
Может все-таки стоит нормально работать с данными на уровне приложения, а не бд? Зачем так укреплять зависимость от конкретного хранилища? |
Re: Защита целосности и структуры данных DB
Цитата:
|
Текущее время: 13:02. Часовой пояс GMT +3. |
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot