Я скорее про процедуру миграции (ну вот например, хотим мы, не знаю, про юзера его предпочитаемый напиток, скажем, хранить). Соответственно, мы хотим добавить поле. Но банальный ALTER TABLE для добавления поля - залочит таблицу на время добавления. Если она большая (например, это не юзеры, а какие-нить эвенты, входы на сайт или клики по баннерам) - это будет долго. И все прочие запросы к этой таблице будут ждать блокировку. Вот и даунтайм. В противовес этому, если таблица денормализована (например, есть JSON-поле, в которое пихается всё дополнительное) - делать с ней вообще ничего не надо. Расплачиваемся скоростью работы с таким полем и вознёй с целостностью, но тут уж куда деваться.
Смысл - делает таблицу с новой структурой, вешает триггеры на все операции со старой таблицей (чтобы дублировались в новую), потом постепенно перетаскивает записи из старой в новую. Потом старая сносится, новая переименовывается.
Сделайте Animal абстрактным и пока везде не замените - оно не скомпилируется.
А то можно написать IAnimal, IVoiceable, IMoveable, IWhateverIImaginedWillBeNecessaryable, а потом окажется, что вы теперь вместо зоопарка делаете ферму и нужны растения. А от животных остаётся только собака, чтоб охранять.
А это и не важно. Ваш оппонент о том, что может быть так: миллион юзеров, из них 999000 - физики, 1000 - юрики. При этом для физика заполняется 10 полей в таблице, для юрика - 100. Дак вот в таком случае "поля-для-юрика" имеет смысл выпинать в отдельную таблицу и сделать 1-to-1 связь. Экономия потому что.
Гхм. А расскажите, пожалуйста, как сделать так, чтобы "дропнуть-добавить" было дёшево? Или, более формально, как "не больно" менять структуру БД. Естественно, в боевых условиях (в таблице сотня миллионов записей, длинный даунтайм делать нельзя, изменения должны быть автоматизированы, поскольку экземпляр приложения далеко не один). У меня всегда получалась боль с фоновыми миграциями, кодом, который поддерживает обе структуры БД и прочими костылями. Не говоря уже о том, что в некоторых СУБД (привет, MySQL и его форки) надо плясать с бубном, чтобы без даунтайма структуру менять.
Это если вы настолько крупный (в смысле организация), что у вас есть отдельный DBA.
А если его нету, то мидл вместо запроса с лефт-райт-джойнами накодит find()->joinWith()->all() через ORM и будет в коде приложения разгребать то, что получилось.
ИМХО, вот в тот момент, когда начинают получаться макароны - и надо рефакторить в полиморфизмы и прочие абстрактные фабрики. И только в том месте, где начали получаться макароны. А сеньор - тот, кто может написать простой код так, чтобы его потом было не больно рефакторить в абстрактный.
Имел дело с системой, в которой подобный подход применялся. На практике не очень удобно (сложнее следить за целостностью, лишние запросы каждый раз, когда объект достать надо (ну хорошо, не запросы, а блокировки центральной таблицы)). Потому считаю что в таком случае проще на каждый тип объекта свою таблицу создать, поля пусть одинаковые и дублируются, а логику в базовый класс вынести.
А ещё есть пример, когда мы делаем модульное приложение и модули к нему пишутся отдельно (может быть даже другой командой). И вот тогда сущность-из-модуля может иметь 1-to-1 связь с сущностью из основного приложения.
Умеют, да. Более того, штатная установка той же SUSE исходный образ системы подключает просто как один из репов (с меньшим приоритетом).
Но софт, который есть в репе дистрибутива, коллекционировать-то особо смысла не имеет, это правда (разве что для инсталляции в условиях "без интернета" (увы, такое встречается)). А вот альтернативный - если его в репах нет, на новой версии дистрибутива бинарник может и не завестись.
Иногда не очень понятно, что именно хочется в системе сделать. Ну типа "хочу запустить IDE, потом мне надо скачать какой-то файлик - нужен браузер, потом этот файлик надо посмотреть-поредактировать - текстовый редактор ну итд". Ну т.е. когда работаешь - мало ли что потребуется. Ну и получается - запустил через терминал что-то, оно работает. Хочу ещё что-то запустить - первое в фон, запустил. Потом было бы неплохо список "чего я тут поназапускал". А еще окошки группировать. И какое-нить меню для переключения. И список "чего ещё можно запустить". Ой, кажется получается DE :-D
А вот тут не соглашусь. В новой версии софта могут отпилить какую-то ключевую для тебя фичу (или перекроить UI, или сломать совместимость с чем-то). Пример из mobile development - новые версии фреймворков и движков (Xamarin, Unity) дропают поддержку старых версий Android, например. Или браузеры из которых выпиливают флеш и ActiveX.
А ещё новая версия может ВНЕЗАПНО потребовать денег на покупку себя. Можно поискать бесплатные аналоги, но зачем, если предыдущая версия уже куплена и в общем-то не ломается, если её специально не ломать?
А ещё, если софт не собирать, а ставить из репозиториев - репозитории имеют свойство "протухать". Можно конечно сделать себе локальное зеркало всех нужных репозиториев, но это кажется уже подходит под определение "собирать софт" (в смысле коллекционирования, а не в смысле компиляции, ага).
И в конце концов, обновлённая версия софта под новую систему может просто не существовать. Разработчик обанкротился или просто перестал софт поддерживать - и всё, как только в ОС сломается обратная совместимость, софт тоже использовать будет нельзя.
Да, эти проблемы решаются, если от софта доступны исходники, если у вас есть знания и навыки, чтобы его из этих исходников собрать, если у вас есть время, чтобы этим заниматься и чинить вылезающие проблемы. В общем, слишком много если.
Справедливости ради, линуксовый подход к управлению софтом имеет свои неоспоримые плюсы. Вопрос в том, что подходит лучше под имеющиеся условия. На домашнем компе (где может быть много проприетарного софта, утилит от всяких китайских девайсов и прочего такого) - лучше работает подход винды (максимум обратной совместимости). На серверах (где софт обычно более-менее стандартный и почти весь open source) - линуксовый. ИМХО, конечно.
Конкретную софтину запустить - да, работает (хотя и выглядит если честно как костыль - пойди по SSH, там запусти, потом только получишь гуй). А вот чтобы весь DE прогрузился (и чтобы работало не очень тормозно) - у меня не вышло.
Ну да, делать OLTP на Hive - это что-то совсем странное.
Я скорее про процедуру миграции (ну вот например, хотим мы, не знаю, про юзера его предпочитаемый напиток, скажем, хранить). Соответственно, мы хотим добавить поле.
Но банальный ALTER TABLE для добавления поля - залочит таблицу на время добавления. Если она большая (например, это не юзеры, а какие-нить эвенты, входы на сайт или клики по баннерам) - это будет долго. И все прочие запросы к этой таблице будут ждать блокировку. Вот и даунтайм.
В противовес этому, если таблица денормализована (например, есть JSON-поле, в которое пихается всё дополнительное) - делать с ней вообще ничего не надо.
Расплачиваемся скоростью работы с таким полем и вознёй с целостностью, но тут уж куда деваться.
Я для такого использовал pt-online-schema-change из Percona Toolkit
https://www.percona.com/software/database-tools/percona-toolkit
Смысл - делает таблицу с новой структурой, вешает триггеры на все операции со старой таблицей (чтобы дублировались в новую), потом постепенно перетаскивает записи из старой в новую. Потом старая сносится, новая переименовывается.
Но больно, да.
Сделайте Animal абстрактным и пока везде не замените - оно не скомпилируется.
А то можно написать IAnimal, IVoiceable, IMoveable, IWhateverIImaginedWillBeNecessaryable, а потом окажется, что вы теперь вместо зоопарка делаете ферму и нужны растения. А от животных остаётся только собака, чтоб охранять.
А это и не важно. Ваш оппонент о том, что может быть так: миллион юзеров, из них 999000 - физики, 1000 - юрики. При этом для физика заполняется 10 полей в таблице, для юрика - 100.
Дак вот в таком случае "поля-для-юрика" имеет смысл выпинать в отдельную таблицу и сделать 1-to-1 связь.
Экономия потому что.
Гхм. А расскажите, пожалуйста, как сделать так, чтобы "дропнуть-добавить" было дёшево? Или, более формально, как "не больно" менять структуру БД. Естественно, в боевых условиях (в таблице сотня миллионов записей, длинный даунтайм делать нельзя, изменения должны быть автоматизированы, поскольку экземпляр приложения далеко не один).
У меня всегда получалась боль с фоновыми миграциями, кодом, который поддерживает обе структуры БД и прочими костылями.
Не говоря уже о том, что в некоторых СУБД (привет, MySQL и его форки) надо плясать с бубном, чтобы без даунтайма структуру менять.
Это если вы настолько крупный (в смысле организация), что у вас есть отдельный DBA.
А если его нету, то мидл вместо запроса с лефт-райт-джойнами накодит find()->joinWith()->all() через ORM и будет в коде приложения разгребать то, что получилось.
Да, в вашем случае получается плюсов у варианта с центральной таблицей больше.
ИМХО, вот в тот момент, когда начинают получаться макароны - и надо рефакторить в полиморфизмы и прочие абстрактные фабрики. И только в том месте, где начали получаться макароны.
А сеньор - тот, кто может написать простой код так, чтобы его потом было не больно рефакторить в абстрактный.
Имел дело с системой, в которой подобный подход применялся. На практике не очень удобно (сложнее следить за целостностью, лишние запросы каждый раз, когда объект достать надо (ну хорошо, не запросы, а блокировки центральной таблицы)).
Потому считаю что в таком случае проще на каждый тип объекта свою таблицу создать, поля пусть одинаковые и дублируются, а логику в базовый класс вынести.
А ещё есть пример, когда мы делаем модульное приложение и модули к нему пишутся отдельно (может быть даже другой командой).
И вот тогда сущность-из-модуля может иметь 1-to-1 связь с сущностью из основного приложения.
А кто-нибудь мне расскажет шутку про DHCP?
Я бы рассказал вам шутку про UDP, да боюсь не дойдёт.
Умеют, да. Более того, штатная установка той же SUSE исходный образ системы подключает просто как один из репов (с меньшим приоритетом).
Но софт, который есть в репе дистрибутива, коллекционировать-то особо смысла не имеет, это правда (разве что для инсталляции в условиях "без интернета" (увы, такое встречается)). А вот альтернативный - если его в репах нет, на новой версии дистрибутива бинарник может и не завестись.
Иногда не очень понятно, что именно хочется в системе сделать. Ну типа "хочу запустить IDE, потом мне надо скачать какой-то файлик - нужен браузер, потом этот файлик надо посмотреть-поредактировать - текстовый редактор ну итд". Ну т.е. когда работаешь - мало ли что потребуется.
Ну и получается - запустил через терминал что-то, оно работает. Хочу ещё что-то запустить - первое в фон, запустил. Потом было бы неплохо список "чего я тут поназапускал". А еще окошки группировать. И какое-нить меню для переключения. И список "чего ещё можно запустить". Ой, кажется получается DE :-D
А вот тут не соглашусь.
В новой версии софта могут отпилить какую-то ключевую для тебя фичу (или перекроить UI, или сломать совместимость с чем-то). Пример из mobile development - новые версии фреймворков и движков (Xamarin, Unity) дропают поддержку старых версий Android, например. Или браузеры из которых выпиливают флеш и ActiveX.
А ещё новая версия может ВНЕЗАПНО потребовать денег на покупку себя. Можно поискать бесплатные аналоги, но зачем, если предыдущая версия уже куплена и в общем-то не ломается, если её специально не ломать?
А ещё, если софт не собирать, а ставить из репозиториев - репозитории имеют свойство "протухать". Можно конечно сделать себе локальное зеркало всех нужных репозиториев, но это кажется уже подходит под определение "собирать софт" (в смысле коллекционирования, а не в смысле компиляции, ага).
И в конце концов, обновлённая версия софта под новую систему может просто не существовать. Разработчик обанкротился или просто перестал софт поддерживать - и всё, как только в ОС сломается обратная совместимость, софт тоже использовать будет нельзя.
Да, эти проблемы решаются, если от софта доступны исходники, если у вас есть знания и навыки, чтобы его из этих исходников собрать, если у вас есть время, чтобы этим заниматься и чинить вылезающие проблемы. В общем, слишком много если.
Справедливости ради, линуксовый подход к управлению софтом имеет свои неоспоримые плюсы. Вопрос в том, что подходит лучше под имеющиеся условия. На домашнем компе (где может быть много проприетарного софта, утилит от всяких китайских девайсов и прочего такого) - лучше работает подход винды (максимум обратной совместимости). На серверах (где софт обычно более-менее стандартный и почти весь open source) - линуксовый. ИМХО, конечно.
Надо будет попробовать. Правда сходу так - пакеты только под Debian (серверные имеется в виду).
Конкретную софтину запустить - да, работает (хотя и выглядит если честно как костыль - пойди по SSH, там запусти, потом только получишь гуй).
А вот чтобы весь DE прогрузился (и чтобы работало не очень тормозно) - у меня не вышло.
Да, действительно, не подумал, что установщик может 16-битным быть.
В любом случае, я всего лишь хотел намекнуть, что "собрать коллекцию привычного софта" под винды существенно проще, чем под линукс.
Это если бы он для Windows 3.1/3.11 был бы собран - тогда да, 16-битный.
А Windows 98 это уже вполне себе 32 бита.