Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Контроль версий на сервере и организация отладки (2 стр)

Контроль версий на сервере и организация отладки (2 стр)

Поделиться

Страницы: 1 2

9К720Участникwww30 июля 201723:41#15
tac
> ты зарегистрирован только 5 лет как :)
Лол.

tac
> и не разу не пожалел), все через хранимые процедуры.
Если логика там не сложнее CRUD - то хранимые процедуры не нужны. Если сложнее - то тем более. Отлаживать их и разбирать инциденты становится невозможным.

Татарин
> ткатить такой скрипт нельзя его присутствие в репозитории бесмысле
С чего это? К скрипту должен быть его же rollback. Для многих операций тот же liquidbase может сделать это самостоятельно.

tac
> Изменения в таблицах можно делать сразу,
Ну удачи тебе добавить колонку в таблицу с миллионами записей, например.

tac
> чем ? общие слова
Тем что sql это самый гибкий из всех возможных способов доступа к базам, а реляционные базы - самые универсальные. Исторически так сложилось.

Татарин
> за такую технологию многие бы сказали спасибо
Для такой технологии надо иметь опыт побольше чем в школьной команде как у ТС. Потому что ТС не в курсе про аудит базы, про ее безопасность, про бакапы, про шифрование, про флешбеки, про инкрементальные бакапы, про мониторинг на различных уровнях, про контроль доступа и еще кучу других вещей. Это все должно быть в нормальной базе и совместимо с существующими практиками администрирования и разработки, о которых ТС тоже не в курсе. Это не наезд, а констатация факта простая. Если бы ТС был в курсе всего этого, он бы не спрашивал на форумах вопросы вроде нуль-поста, а консультации по архитектуре построения и обслуживания баз давал бы, от 500 баксов в час.

Правка: 30 июля 2017 23:44

kiparПостоялецwww30 июля 201723:46#16
tac
> если конечно не выделываться и не переименовывать старые поля.
А если, например, была таблица с ид, ..., класс_персонажа, а потом надо сделать мультикласс и выделить в отдельную таблицу один-ко-многим?
Или удалили поле веса прдмета т.к. оно стало вычисляемым.
Хотя наверное можно каждый такой случай хитрыми view разрулить, но не более ли это нудная проблема чем хранить скрипты миграций.

В общем довольно специфичное решение - только для небольших изменений, только для тех у кого весь доступ через хранимые процедуры, только для тех кому не влом при каждом изменении следить чтобы старая версия не поломалась.

tacПостоялецwww31 июля 20170:21#17
kipar
> но не более ли это нудная проблема чем хранить скрипты миграций
kipar
> только для небольших изменений
какая то странная оценка .. скрипты - нужно хранить ВСЕГДА на каждое изменение, и потом еще разруливать конфликты ... а изменения в таблицах, сколь либо существенно влияющие на работоспособность - это 5% всех случаев

kipar
> удалили поле веса прдмета т.к. оно стало вычисляемым
не надо так, вначале сделай вычисляемое поле, а перейди на него, а когда устаканится - удали

kipar
> была таблица с ид, ..., класс_персонажа, а потом надо сделать мультикласс и
> выделить в отдельную таблицу один-ко-многим?
этот пример не понял, была нарушена 3 нормальная форма? не надо так

kipar
> только для тех кому не влом при каждом изменении следить чтобы старая версия не
> поломалась
или не понял, или как раз речь и идет о том, чтобы игроки могли играть на старой версии, пока отлаживается новая

kipar
> только для тех у кого весь доступ через хранимые процедуры
ну я надеюсь таких неадекватов


9К720
> Если логика там не сложнее CRUD - то хранимые процедуры не нужны. Если сложнее
> - то тем более. Отлаживать их и разбирать инциденты становится невозможным.

практически нет ... ну а если они вбили себе в голову бред - ну их проблемы

Правка: 31 июля 2017 0:22

kiparПостоялецwww31 июля 20170:51#18
tac
> или не понял, или как раз речь и идет о том, чтобы игроки могли играть на
> старой версии, пока отлаживается новая
да, речь о том что при любом изменении таблиц придется дополнительно проверять, чтобы оно работало со старым кодом и старой базой. И в тех 5-10% случаев когда работать не будет - придется придумывать и добавлять костыли.
По-моему проще хранить скрипты всегда, там никакой фантазии не требуется.
А для отлаживаемой версии в любом случае использовать тестовый сервер с отдельной базой. Сначала обновления таблиц выкатывать туда, потом и на основной.

> этот пример не понял, была нарушена 3 нормальная форма? не надо так
Почему нарушена? Было - у каждого персонажа есть ровно одна профессия. ид профессии хранился в таблице персонажей. И одно имя. И один пол и раса. А потом сделали что профессий (или рас, или имен, или даже полов) можно иметь несколько. Или что, надо было сразу по 6 таблиц заводить, имя в одной, а пол в другой?

tacПостоялецwww31 июля 20171:41#19
kipar
> Почему нарушена? Было - у каждого персонажа есть ровно одна профессия. ид
> профессии хранился в таблице персонажей. И одно имя. И один пол и раса. А потом
> сделали что профессий (или рас, или имен, или даже полов) можно иметь
> несколько.
потомушта ... классическое нарушение 3 нормальной формы, учим мат. часть

kipar
> Или что, надо было сразу по 6 таблиц заводить, имя в одной, а пол в другой?
прикинь - именно так, пропускал лекции по базам данных? Только с полом ты перестарался - это просто поле с двумя значениями (хотя если строго то да и тут нарушение, но как тут поступают - не должно быть поля Sex, а должно быть поле SexID - а уже вводить таблицу с названиями мужской/женский - иногда лень и можно ввести когда понадобится)

вот от сюда у многих и любовь к NoSQL ... и прочему объектному бреду в БД - просто где-то видимо пробелы в образовании

Правка: 31 июля 2017 2:52

tacПостоялецwww31 июля 20171:46#20
kipar
> По-моему проще хранить скрипты всегда, там никакой фантазии не требуется.
> А для отлаживаемой версии в любом случае использовать тестовый сервер с
> отдельной базой.
согласен надежнее (чуть-чуть, но не проще) , но приводит к тому, что не реально развертывание (описанное выше мной) выполнить по одному щелчку - а это означает увеличении трудоемкости при выпуске версии

Правка: 31 июля 2017 2:03

kiparПостоялецwww31 июля 20178:42#21
tac
Ясно, мало того что доступ только по хранимым процедурам, так ещё и не больше одного значащего поля на таблицу. Нет, я уж лучше как-нибудь с миграциями проживу.
——
Аааа, до меня дошло. Недопонимание вышло, сорри. Ты имеешь в виду что как и с полом - в базе будет числовой идентификатор. Просто в старой версии он будет сразу идентификатором класса, а в новой - ключом промежуточной таблицы. Тогда да, неудачный пример.

Допустим было в аккаунте поле email. Его то, надеюсь, есть смысл напрямую хранить, без лишних таблиц?
А потом сделали что емэилов может быть много (или ни одного), соответственно теперь храним вместо него ключ промежуточной таблицы.

Правка: 31 июля 2017 11:24

tacПостоялецwww31 июля 201712:35#22
kipar
> не больше одного значащего поля на таблицу
что то тут я не понял, если под значащим полем ты имеешь введу первичный ключ, то да ... иначе бред какой то

Правка: 31 июля 2017 12:35

tacПостоялецwww31 июля 201712:41#23
kipar
> Допустим было в аккаунте поле email. Его то, надеюсь, есть смысл напрямую
> хранить, без лишних таблиц?
> А потом сделали что емэилов может быть много (или ни одного), соответственно
> теперь храним вместо него ключ промежуточной таблицы.
да, этот пример много лучше ... по сути сводится к

tac
> kipar
> > удалили поле веса прдмета т.к. оно стало вычисляемым
> не надо так, вначале сделай вычисляемое поле, а перейди на него, а когда
> устаканится - удали

вначале, вводим по новому ... устаканивается, и удаляем старое поле email ... пишем задание sql скрипт на перенос из старого поля в новую таблицу, и проставляем ID мейлов (все равно это новое поле EmailID)

P.S. вообще говоря - 5% фейлов при таком подходе я накинул просто на не внимательность ... там скорее хуже, когда надо в таблицах под одним ID в старой и новой версии что-то поменять ... например, вес продукта в старой версии был 5кг., а в новой побалансировали и решили сделать 7кг. ... вот это менять сложнее ... а со структурами таблиц - все отработано на практике - там простая наука, как изменить не затронув прошлые версии

Правка: 31 июля 2017 12:48

Страницы: 1 2

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр