Да, вы правы, можно и в обертке, но только это лишнее усложнение кода, поскольку создается функция, которая в принципе не нужна. Ну и ко всему прочему вызов функции все-таки немного помедленнее безусловного перехода. Это как в тройном вложенном цикле, можно тупо goto, а можно наворотить кучу флагов и ненужных проверок.
Я вам могу привести реальный пример на си. Как вы знаете, в большинстве случаев сишные функции в качестве результата возвращают ноль или код ошибки. Допустим вам надо сделать последовательный вызов 10 функций, причем каждая последующая вызывается только после успешного окончания предыдущей. В случае неуспеха надо допустим вернуть номер упавшей функции по порядку.
Код без goto
Также учтите, что в exit может стоять освобождение выделенных в куче ресурсов, а с множеством return'ов вам это освобождение придется вписывать везде.
В общем я за гото именно в таких случаях, поскольку он упрощает код и облегчает его понимание. Но безусловно я против, когда гото используется просто потому, что «программист» не может описать свою задачу алгоритмически. И повторюсь, это для си, в плюсах естественно все по-другому.
И в чем тут, позвольте спросить, извращение? я подобным образом у себя в проекте на С реализовал, правда я обернул в макрос, чтобы длину строки не считать. Единственное — плохо читается, но если разбивать на переменные, то теряем ленивую оптимизацию.
Не совсем те же яйца, там еще есть управление зависимостями сервисов, то есть sshd, например, раньше сети не запустится. Это по-моему гораздо удобнее, чем распихивать скрипты по разным папкам с номерами.
Ну в частности в моем проекте воркеры между собой не общаются. Они общаются либо с именованными процессами, либо с супервайзером. Поэтому я слегка и не понял задумки.
Вообще у меня возникла такая идея — прикрутить эту диспетчиризацию к супервайзеру. Он знает, какие у него дети присутствуют и в качестве идентификатора может быть любой терм. Просто подсознательно идея с глобальным состоянием меня пугает. Единственное — я не вижу в доке способ получения спеки одного дочернего процесса, только which_children. Но думаю, что это можно обойти.
Опять же, я не настолько искушен в этом деле. Наверно просто я сам не встречался с такими задачами. Но в моих задачах есть либо именованные процессы, к которым надо обращаться по имени, либо воркеры, к которым обращение идет через pid либо они первые начинают) Но все равно спасибо, будем знать, что к чему и если возникнет необходимость — использовать.
Создание или обновление. Если создание, то понятно. Вот если обновление, то это уже сложнее. Но в любом случае что мешает поднять вторую ноду? У кауча репликация мастер-мастер, то есть вы сможете коннектиться в любой из нод, и таким образом перераспределять нагрузку. Если я не прав — поправьте меня.
Вся прелесть как раз вот в таких преиндексированных вьюхах. Иначе весь смысл пропадает. Я не знаю, как у этим с монго.
Каждый раз запрос будет обрабатываться заново, пусть по индексам, но заново. Можно конечно закешировать, но что делать при обновлениях, вешать триггеры, а потом судорожно искать баги? А вот в кауче написав однажды вьюху при обновлении данных она будет обновляться автоматически, причем весьма быстро.
Ага, щаззз
Если есть индексы по нужным полям. это раз.
Два, если таких запросов по разным полям у вас много, то индексов будет дофига. Соотвественно вставка у вас будет «весьма быстрой».
И 3 для аналитики надо использовать OLAP в связке с другим хранилищем с регулярной выгрузкой данных из него в OLAP. Да, мы не сможем получить мгновенный отчет на данную минут, но это чаще всего и не требуется, зато запросы будут действительно мгновенные и вставка не будет тормозить.
1. А люди думают, что NoSQL — это только простейшие хешмапы, а map/reduce — деление одного английского глагола на другой :)
2. Про то, что для запросов в map/reduce вообще не нужно специального языка (например в монго и кауче используется совершенно обычный javascript) они тоже не в курсе. И то, что это не тупой перебор всех документов по очереди, тоже не подозревают
3. Про то, что аналитика на SQL при огромных хранилищах — самоубийство, тоже не в курсе. Нормальные люди используют OLAP.
4. Я не знаю, что это такое, поэтому промолчу
Ну так key-value семейство и предназначено для хранения key-value. Если вам нужна выборка по полю, то делайте дублирование и добавляйте записи у которых ключом будет это поле, а значением — набор объектов. Ну либо используйте что-то более подходящее.
Скажу я. Не могу сказать за все СУБД, потому буду про кауч.
В NoSQL нет джойнов. соответсвенно если у вас большое число разнотипных и больших оьъектов, связанных между собой, то хранение их в кауче (а точнее выборка) будет не слишком эффективно и вот почему.
Если хранить с полем, содержащим идентификатор связанного документа, то можно будет сделать квази-джойн на 1 уровень в глубину (на самом деле это не джойн, а просто сахар, для связанного id уже после мапа прогружается документ). Обсуловлено это тем, что функция map (в которой собственно происходит выборка) явяется чистой и для получения результата может пользоваться только переданным ей документом. Это нужно для оптимизации автоматического построения и обновления индексов.
Есть вариант хранения многоуровневой иерархии в одном документе, но это содержит ряд недостатков.
1. Документу нельзя только обновить поле. Надо загрузить документ, исправить поле и залить документ. Отсюда получаем, что для больших документов будет неэффективно.
2. Если требуется часто менять вложенные подобъекты, то вам придется самому озаботиться обновлением этих подобъектов во всех документах. Кстати аналогично будет и при денормализации БД в РСУБД.
Поэтому для себя делаю вывод, что в частности кауч подходит для хранения плоских или почти плоских моделей, без глубоких взаимосвязей. Причем оптимально его использовать для моделей с нечеткой структурой. НУ и само собой, когда нужна или планируется горизонтальная масштабируемость.
Код без goto
Случай с гото
Также учтите, что в exit может стоять освобождение выделенных в куче ресурсов, а с множеством return'ов вам это освобождение придется вписывать везде.
В общем я за гото именно в таких случаях, поскольку он упрощает код и облегчает его понимание. Но безусловно я против, когда гото используется просто потому, что «программист» не может описать свою задачу алгоритмически. И повторюсь, это для си, в плюсах естественно все по-другому.
Второй про Гитлера вроде
а уже отменили? Или я что-то неправильно помню?
Вообще у меня возникла такая идея — прикрутить эту диспетчиризацию к супервайзеру. Он знает, какие у него дети присутствуют и в качестве идентификатора может быть любой терм. Просто подсознательно идея с глобальным состоянием меня пугает. Единственное — я не вижу в доке способ получения спеки одного дочернего процесса, только which_children. Но думаю, что это можно обойти.
Что вы думаете по поводу этой идеи?
Вся прелесть как раз вот в таких преиндексированных вьюхах. Иначе весь смысл пропадает. Я не знаю, как у этим с монго.
Если есть индексы по нужным полям. это раз.
Два, если таких запросов по разным полям у вас много, то индексов будет дофига. Соотвественно вставка у вас будет «весьма быстрой».
И 3 для аналитики надо использовать OLAP в связке с другим хранилищем с регулярной выгрузкой данных из него в OLAP. Да, мы не сможем получить мгновенный отчет на данную минут, но это чаще всего и не требуется, зато запросы будут действительно мгновенные и вставка не будет тормозить.
2. Про то, что для запросов в map/reduce вообще не нужно специального языка (например в монго и кауче используется совершенно обычный javascript) они тоже не в курсе. И то, что это не тупой перебор всех документов по очереди, тоже не подозревают
3. Про то, что аналитика на SQL при огромных хранилищах — самоубийство, тоже не в курсе. Нормальные люди используют OLAP.
4. Я не знаю, что это такое, поэтому промолчу
В NoSQL нет джойнов. соответсвенно если у вас большое число разнотипных и больших оьъектов, связанных между собой, то хранение их в кауче (а точнее выборка) будет не слишком эффективно и вот почему.
Если хранить с полем, содержащим идентификатор связанного документа, то можно будет сделать квази-джойн на 1 уровень в глубину (на самом деле это не джойн, а просто сахар, для связанного id уже после мапа прогружается документ). Обсуловлено это тем, что функция map (в которой собственно происходит выборка) явяется чистой и для получения результата может пользоваться только переданным ей документом. Это нужно для оптимизации автоматического построения и обновления индексов.
Есть вариант хранения многоуровневой иерархии в одном документе, но это содержит ряд недостатков.
1. Документу нельзя только обновить поле. Надо загрузить документ, исправить поле и залить документ. Отсюда получаем, что для больших документов будет неэффективно.
2. Если требуется часто менять вложенные подобъекты, то вам придется самому озаботиться обновлением этих подобъектов во всех документах. Кстати аналогично будет и при денормализации БД в РСУБД.
Поэтому для себя делаю вывод, что в частности кауч подходит для хранения плоских или почти плоских моделей, без глубоких взаимосвязей. Причем оптимально его использовать для моделей с нечеткой структурой. НУ и само собой, когда нужна или планируется горизонтальная масштабируемость.