Действительно — это так. Рынок считается привлекательным пока прибыль выше нуля
При идеальной конкуренции — прибыль равна нулю.
Чего никогда не бывает на практике.
«Увеличивать цены на загрузку сайтов из США — это действительно насущная необходимость, представьте, сколько много оборудования задействовано при пересылке пакетов из Москвы в Нью-Йорк» — звучит бредово, да?
я так понимаю, что это значит примерно следующее:
если для того, чтобы доказать определенную теорию — роботу надо перебрать бесконечное количество вариантов, то эту теорию робот не докажет, какой мощный он бы ни был.
и, таки, какие преимущества у NS и NI по сравнению с предложенным в статье способом, кроме того что не используется дополнительная таблица (и преимущество ли это?)
выше есть уже два сообщения по этому поводу. плюс мне не нравится идеология этого метода. я не говорю, что она плохая, я говорю, что она мне не нравится. Не нравится точно так же, как не нравятся суши. Понимаешь о чём я?
Я понимаю что parentlevel не нужен, но если его добавить, то пример ни чем отличается от вашего.
Если вы так говорите, значит вы или не читали статью, или читали её невнимательно.
чтобы показать все элементы 2 уровня надо буде написать:
Да, но так вы получите только один уровень. Но как получить всё дерево под определенным элементом?
В способе, который предложен в сабже ключевое не уровень элемента, а список ID всех родителей. Таким образом, выбрав определенный ID мы можем простым поиском по индексам найти список всех его детей, независимо от уровня вложенности.
я думаю, что все здесь знают о недостатках Nested Sets. Кто-то с этими недостатками смирился, но меня они — не устраивают. Особенно, по той причине, что есть альтернатива лучше.
если сделать одну таблицу, то parentlevel не нужен, так как в parentid мы можем записать айди единственного элемента. — ближайшего и parentlevel будет у него 1. Если я правильно понял, о чём вы. Этот способ самый известный и логичный, и называется Adjacency List и его главный недостаток — выборка всего дерева начиная от определенной ветки, так как надо выбирать дерево рекурсивно, или другим способом — так же не очень производительным. Этот способ достаточно известен и в интернете можно найти список его недостатков)
Вы уж простите, но я не совсем вас понял.
Давайте начнём с того: какой способ вы предлагаете для хранения иерархических структур и чем этот способ лучше представленного в статье.
Объясните также — что мне мешает писать сложные запросы в данном примере? Для меня удивительно такое заявление.
Зачем мне тысячи мелких select'ов?
При идеальной конкуренции — прибыль равна нулю.
Чего никогда не бывает на практике.
только хотел тоже самое сказать
если для того, чтобы доказать определенную теорию — роботу надо перебрать бесконечное количество вариантов, то эту теорию робот не докажет, какой мощный он бы ни был.
вообще действительно на личности начался переход, потому я выхожу из этой обсуждения в этой ветке.
Ну. Согласно тестам — производительность намного больше, чем в МП. Или вы исключительно про апдейты?
Объясните, а откуда такая всеобщая боязнь JOIN'ов?
Почему-то я не сомневаюсь, что в любой СУБД это дело очень хорошо оптимизированно
Ммм, какая интересная информация. Пруфлинк?
При необходимости — еще одним полем в таблице иерархии, по которому осуществляется сортировка
В NS и NI, в отличии от FH не создается еще одна таблица, что можно отнести к преимуществам.
Если вы так говорите, значит вы или не читали статью, или читали её невнимательно.
Да, но так вы получите только один уровень. Но как получить всё дерево под определенным элементом?
В способе, который предложен в сабже ключевое не уровень элемента, а список ID всех родителей. Таким образом, выбрав определенный ID мы можем простым поиском по индексам найти список всех его детей, независимо от уровня вложенности.
Давайте начнём с того: какой способ вы предлагаете для хранения иерархических структур и чем этот способ лучше представленного в статье.
Объясните также — что мне мешает писать сложные запросы в данном примере? Для меня удивительно такое заявление.
Зачем мне тысячи мелких select'ов?