+ была практика иметь 2-3 конкурирующих исполнителя на высоком уровне (Ил/МиГ/Су — авиация, Харьков/Уралвагонзавод — танки, Камов/Миль — вертолёты и т.п.). Почему-то сейчас считается что конкуренция присуща исключительно капиталистической форме организации труда…
Hash join — один из лучших способов соединения таблиц
скажем так, не бесспорное утверждение. Зависит от характера и объёма данных на которых происходит это соединение. Если данных мало Nested loops будет быстрее. Если данные упорядочены Merge join будет и быстрее и эффективнее с точки зрения памяти.
Можно даже попытаться перефразировать Черчилля для случая большого количества неупорядоченных данных: «Hash join — отвратительный вариант соединения больших неупорядоченных таблиц, но все остальные ещё хуже» :)
Судя по всему вам удалось и то и другое. Не обижайтесь, я не имел в виду ничего плохого. Просто я неверно понял исходные условия. После их выяснения всё стало понятно и правильно.
Ну, изобретение бессмысленного, в реальной жизни, велосипеда в рамках соревнований по изобретению велосипедов — не такое уж бессмысленное занятие :). А в данном случае имел место именно этот вариант, как я понял.
Ок, я готов поверить что применение C++ кардинально отличает задачу от варианта с применением простого C (сделать это непросто, но я готов).
Но я по прежнему не могу понять ответ на вопрос «Зачем?». Для решения какой прикладной задачи вы ввели эти типы? И почему вам было недостаточно тех типов, которые уже есть в PostgreSQL?
Вы слишком серьёзны :)
К тому же это не моя фраза (именно поэтому она взята в кавычки), а вполне расхожий афоризм. Который, как любой афоризм, является «шуткой, в которой есть доля шутки».
Самое время вспомнить сакраментальное: «Любую архитектурную проблему можно решить путём добавления ещё одного уровня абстракции. Любую, кроме проблемы слишком большого количества уровней абстракции...»
«Эгоизм» генов это, разумеется, не некое осмысленное поведение. Это некоторая метафора, описывающая чисто математическую составляющую «жизни репликантов» :)
Ну, и у него не только «Эгоистичный ген», но и «Расширенный фенотип», «Слепой часовщик», «Расплетая радугу» и ещё много чего.
Из предыдущей статьи (тоже, надо сказать, очень хорошей)
Походив с усами энное количество времени, наш фенотип вновь подвергается изменениям, не столь резко как при взрослении, но столько же кардинально – меняется форма ушей, носа, глаз, бровей, цвет волос или даже их отсутствие.
Здесь, как мне кажется присутствует небольшая, но очень важная ошибка. Наш фенотип не «вновь подвергается изменениям». Они просто не перестаёт им подвергаться. То есть эти изменения постоянны. А некоторая наблюдаемая «фазированность» изменений — не более чем визуально наблюдаемый диалектический «переход количества в качество». Условно: после выпадения какого процента волос человек приобретает лысину?
Не столько Докинз, сколько моё понимание Докинза :) Я не биолог, просто интересуюсь.
И я, в данном случае, не про конкретные механизмы старения/умирания (мне для этого не хватает знаний и квалификации), а, скорее, про некий философский аспект проблемы.
Насколько я понимаю — с точки зрения отбора нет ни единого фактора, который бы работал на бессмертие конкретного организма. Гены и так бессмертны. А организм отбору не интересен :) Гены же «заинтересованы» в поддержании организма до достижения некоторой численности потомства (считай обеспечения этого самого бессмертия для генов), а дальше это пустая трата ресурсов.
Так что на мой взгляд нет никаких специальных механизмов «старения/умирания». Это просто проявление отсутствия механизмов поддержания вечной жизни. Не нужны они. Вот и не развились.
Пока, в основном, в мечтах :)
Но в комментариях к одной из приведённых статей звучали термины state-driven deployment и change-driven deployment.
Общая идея, в целом, достаточно проста: у вас должны быть скрипты, описывающие состояние схемы. Из них можно в любой момент собрать любую версию БД «с нуля» (и по ним же посмотреть кто, что и когда изменил). А миграции — это отдельная часть проекта (вторичная по отношению к схеме), причём имея в системе контроля версий состояния вы всегда можете убедиться в том, что ваша миграция делает именно то, что вы хотели (собрав с нуля схему версии N, а рядом версии N-1 + накат на неё миграции и сравнив их между собой).
Это если вкратце.
как посмотреть историю изменений конкретного объекта структуры БД. По каждой таблице хочется посмотреть историю изменений в связи с решением конкретных задач.
Для этого нужно вести не только миграции, но и полноценное версионированное описание схемы. Больше того — это описание первично по отношению к миграциям (которые всего лишь описывают один из бесконечного числа возможных путей перевода БД из состояния А в состояние Б).
скажем так, не бесспорное утверждение. Зависит от характера и объёма данных на которых происходит это соединение. Если данных мало Nested loops будет быстрее. Если данные упорядочены Merge join будет и быстрее и эффективнее с точки зрения памяти.
Можно даже попытаться перефразировать Черчилля для случая большого количества неупорядоченных данных: «Hash join — отвратительный вариант соединения больших неупорядоченных таблиц, но все остальные ещё хуже» :)
Но я по прежнему не могу понять ответ на вопрос «Зачем?». Для решения какой прикладной задачи вы ввели эти типы? И почему вам было недостаточно тех типов, которые уже есть в PostgreSQL?
К тому же это не моя фраза (именно поэтому она взята в кавычки), а вполне расхожий афоризм. Который, как любой афоризм, является «шуткой, в которой есть доля шутки».
Ну, и у него не только «Эгоистичный ген», но и «Расширенный фенотип», «Слепой часовщик», «Расплетая радугу» и ещё много чего.
Из предыдущей статьи (тоже, надо сказать, очень хорошей)
Здесь, как мне кажется присутствует небольшая, но очень важная ошибка. Наш фенотип не «вновь подвергается изменениям». Они просто не перестаёт им подвергаться. То есть эти изменения постоянны. А некоторая наблюдаемая «фазированность» изменений — не более чем визуально наблюдаемый диалектический «переход количества в качество». Условно: после выпадения какого процента волос человек приобретает лысину?
И я, в данном случае, не про конкретные механизмы старения/умирания (мне для этого не хватает знаний и квалификации), а, скорее, про некий философский аспект проблемы.
Так что на мой взгляд нет никаких специальных механизмов «старения/умирания». Это просто проявление отсутствия механизмов поддержания вечной жизни. Не нужны они. Вот и не развились.
Но в комментариях к одной из приведённых статей звучали термины state-driven deployment и change-driven deployment.
Общая идея, в целом, достаточно проста: у вас должны быть скрипты, описывающие состояние схемы. Из них можно в любой момент собрать любую версию БД «с нуля» (и по ним же посмотреть кто, что и когда изменил). А миграции — это отдельная часть проекта (вторичная по отношению к схеме), причём имея в системе контроля версий состояния вы всегда можете убедиться в том, что ваша миграция делает именно то, что вы хотели (собрав с нуля схему версии N, а рядом версии N-1 + накат на неё миграции и сравнив их между собой).
Это если вкратце.
Для этого нужно вести не только миграции, но и полноценное версионированное описание схемы. Больше того — это описание первично по отношению к миграциям (которые всего лишь описывают один из бесконечного числа возможных путей перевода БД из состояния А в состояние Б).