По моему разумению, смысла особого нет.
У меня решений подобных как минимум 5: 2 Perl, 1 PHP, 2 триггеры.
Проще описать все решения, а кому что нравится тот и будет юзать и применять к своим проектам.
Статья ни о чем.
Перевод документации, причем неполный, а в конце, так вообще абзац на каждый тип.
А подводные камни? И вообще:
Например тип MERGE:
1. Только на основе таблиц MyISAM — про это — ни слова. Разве это не важно? А почему только на основе такого типа?
2. цитирую: «не отслеживаются изменения в структуре исходных таблиц (таблица будет поломана)» — Что значит поломана? Что значит не отслеживаются? К чему это приводит? Как это исправить?
3. цитирую: «Рекомендации: «удобная» (ре)организация таблиц» — если честно, данная рекомендация ставит в тупик.
А например, как быть если последнюю новость заблокировал модератор, нужно срочно поменять местами предпоследнюю и последнюю, и т.д. и т.п.? Перестойка даже дельта индекса гораздо медленней, а менеджеры над душой стоят.
А если данные берутся из основного поиска (индекса), так вообще урезается любая возможность маневра.
10 минут для попадания новости в требуемую выдачу — несерьезно.
Что мешает завести вспомогательную таблицу last_news_from_source, которую можно теми же триггерами обновлять во время вставки новой новости?
Вообще я согласен с автором, по моему мнению, собеседование такого формата не самые лучшие.
Скажу сразу, эти вопросы меня поставили в некоторый тупик.
Особенно первый вопрос: «Вы знаете что такое use strict;?».
Честно, я не знал, что ответить, т.к. это звучало как издевательство, с учетом того, что они прекрасно знали о моем опыте.
Следующие вопросы, те, что написал автор, и много всякой фигни не в тему.
Я считаю, что данные примеры — элементы экстремального программирования, причем самые яркие и показательные. Именно примеры с подковыркой. Я с ходу на такие не отвечу, мои коллеги, тоже не ответили. Все потому, что так никто из нас никогда не пишет.
И я на 90 % уверен, что если человек с ходу на них (на эти вопросы) отвечает, что его код примерно так и выглядит. Все это конечно прикольно и здорово, но в большинстве случаев не решает главной задачи веб разработчиков; «Давать ЩАСТЬЕ пользователям». Это такие онанисты, которые дрочат на свой код и умиляются своей крутости. При этом сопровождение и поддержка этого кода им же осуществляется в несколько раз медленнее, так как ему тоже часто надо разобраться самому в своем говнокоде.
Я согласен на подобный код только в одном случае: когда этот код находится на уровне прототипа, причем прототипа, чей алгоритм отработан, вылизан и не подвержен изменениям. Только тогда можно в качестве развлечения поиграть в perl-гольф и бесконечно оптимизировать.
Очень обидно, что компания проводящая такого рода собеседования — это mail.ru (нефиг тут кривляться).
А еще более обидней, что проект, на который так набирают разработчиков — это «Единый школьный портал».
Это проект который предназначен в первую очередь для пользователей, уровня ниже среднего, причем заведомо ниже. Так как он будет обязательным для использования преподавателям всех предметов, а так же рекомендуемым для использования всем родителям школьников. Школьников — не считаем, им проще, они дети, быстро схватят все.
Первую реализацию «Единого школьного портала» все видели, все знают. Ждем очередную говнореализацию.
P.S. Я собеседование это проходил, но результатом не интересовался, для меня это была экскурсия в эту компанию.
P.P.S. Тут еще сказали что-то насчет Яндекса, что мол у них то же самое. Так вот нет, я у них на собеседовании тоже чай пил. В Яндексе мне задавали вопросы исключительно по реальным задачам, без абстракций.
Возможно и задели и не потому, что колен не преклонили.
А потому, что из-за того, что вы не понимаете алгоритма и никогда его не применяли, вы заранее утверждаете что это говно.
Читаем статью еще раз. Вникаем в суть.
Я не предлагаю замены, я предлагаю расширение Nested Sets, что бы его можно было использовать как и Adjacency List.
Сложность поддержки? Хм… если вы не будете менять поля используемые для Nested Sets, то вообще-то эти триггеры изменять не нужно.
Сложность разработки? Какой разработки?
Сложность тестирования? — Расхожее убеждение.
Вообще, если я использую в своих проектах этот алгоритм, то как минимум я знаю как он работает, если вы пять лет назад писали диплом на эту тему и не используете этот алгоритм в практике и не собираетесь, то вам этот код не годится. И что с того?
А о чем?
Я провожу сравнения?
Я проповедую новую религию?
Нет, я предлагаю готовую реализацию, для тех, кто использует данный алгоритм.
Вы то, что тут делаете?
У меня складывается чувство, что я своей статьей чем-то вас обидел, подорвал моральные устои.
Найдите пожалуйста, где я сказал, что Adjacency List — это говно, и не надо его никогда использовать, что LTree говно, или другие решения.
Единственно, на что я посетовал, так это на то что в MySQl реализация триггеров — говно, а MERGE иногда работает, мягко скажем, неадекватно.
Есть алгоритм Nested Sets, вот вам его реализация на уровне триггеров.
Кому надо — используйте, кому не надо, чего рассказывать о том, что это вам не понятно сложно и вообще говно.
А не провожу никаких сравнений, а вам лишь бы хуем померяться.
Диалог совершенно неконструктивен.
Если вы не понимаете алгоритма, не используйте, я же вам его не навязываю.
> что запросы с case/if/триггеры и прочими сложными вещами напрочь сносят возможные выигрыши
Вот тут поподробней пожалуйста. Что сносит, в каких случаях и почему?
Редкость не редкость, но когда у тебя 10 таких полей, и вдруг понадобилось еще 5, а в таблице уже более миллиона записей, и останавливать проект нельзя.
Как показывает практика, заведомое ограничение рано или поздно приводит к тому, что эти ограничения начинают существенно мешать.
Это эксперимент у меня, что можно сделать имея в наличии только SSI и .htaccess.
У меня решений подобных как минимум 5: 2 Perl, 1 PHP, 2 триггеры.
Проще описать все решения, а кому что нравится тот и будет юзать и применять к своим проектам.
habrahabr.ru/blogs/mysql/63883/
habrahabr.ru/blogs/postgresql/63416/
Триггеры не все осилили.
Хотел написать «По заявкам телезрителей», но на самом деле это было нужно мне самому.
Забыл.
Виноват.
Извиняюсь.
Перевод документации, причем неполный, а в конце, так вообще абзац на каждый тип.
А подводные камни? И вообще:
Например тип MERGE:
1. Только на основе таблиц MyISAM — про это — ни слова. Разве это не важно? А почему только на основе такого типа?
2. цитирую: «не отслеживаются изменения в структуре исходных таблиц (таблица будет поломана)» — Что значит поломана? Что значит не отслеживаются? К чему это приводит? Как это исправить?
3. цитирую: «Рекомендации: «удобная» (ре)организация таблиц» — если честно, данная рекомендация ставит в тупик.
Тема «сисек» — не раскрыта.
А если данные берутся из основного поиска (индекса), так вообще урезается любая возможность маневра.
Что мешает завести вспомогательную таблицу last_news_from_source, которую можно теми же триггерами обновлять во время вставки новой новости?
Скажу сразу, эти вопросы меня поставили в некоторый тупик.
Особенно первый вопрос: «Вы знаете что такое use strict;?».
Честно, я не знал, что ответить, т.к. это звучало как издевательство, с учетом того, что они прекрасно знали о моем опыте.
Следующие вопросы, те, что написал автор, и много всякой фигни не в тему.
Я считаю, что данные примеры — элементы экстремального программирования, причем самые яркие и показательные. Именно примеры с подковыркой. Я с ходу на такие не отвечу, мои коллеги, тоже не ответили. Все потому, что так никто из нас никогда не пишет.
И я на 90 % уверен, что если человек с ходу на них (на эти вопросы) отвечает, что его код примерно так и выглядит. Все это конечно прикольно и здорово, но в большинстве случаев не решает главной задачи веб разработчиков; «Давать ЩАСТЬЕ пользователям». Это такие онанисты, которые дрочат на свой код и умиляются своей крутости. При этом сопровождение и поддержка этого кода им же осуществляется в несколько раз медленнее, так как ему тоже часто надо разобраться самому в своем говнокоде.
Я согласен на подобный код только в одном случае: когда этот код находится на уровне прототипа, причем прототипа, чей алгоритм отработан, вылизан и не подвержен изменениям. Только тогда можно в качестве развлечения поиграть в perl-гольф и бесконечно оптимизировать.
Очень обидно, что компания проводящая такого рода собеседования — это mail.ru (нефиг тут кривляться).
А еще более обидней, что проект, на который так набирают разработчиков — это «Единый школьный портал».
Это проект который предназначен в первую очередь для пользователей, уровня ниже среднего, причем заведомо ниже. Так как он будет обязательным для использования преподавателям всех предметов, а так же рекомендуемым для использования всем родителям школьников. Школьников — не считаем, им проще, они дети, быстро схватят все.
Первую реализацию «Единого школьного портала» все видели, все знают. Ждем очередную говнореализацию.
P.S. Я собеседование это проходил, но результатом не интересовался, для меня это была экскурсия в эту компанию.
P.P.S. Тут еще сказали что-то насчет Яндекса, что мол у них то же самое. Так вот нет, я у них на собеседовании тоже чай пил. В Яндексе мне задавали вопросы исключительно по реальным задачам, без абстракций.
— Ты видишь в поле суслика?
— Нет.
— Но тем не менее он там есть.
doc.prototypes.ru/database/nestedsets/theory/rules/
А потому, что из-за того, что вы не понимаете алгоритма и никогда его не применяли, вы заранее утверждаете что это говно.
Я не предлагаю замены, я предлагаю расширение Nested Sets, что бы его можно было использовать как и Adjacency List.
Сложность разработки? Какой разработки?
Сложность тестирования? — Расхожее убеждение.
Вообще, если я использую в своих проектах этот алгоритм, то как минимум я знаю как он работает, если вы пять лет назад писали диплом на эту тему и не используете этот алгоритм в практике и не собираетесь, то вам этот код не годится. И что с того?
Я провожу сравнения?
Я проповедую новую религию?
Нет, я предлагаю готовую реализацию, для тех, кто использует данный алгоритм.
Вы то, что тут делаете?
Найдите пожалуйста, где я сказал, что Adjacency List — это говно, и не надо его никогда использовать, что LTree говно, или другие решения.
Единственно, на что я посетовал, так это на то что в MySQl реализация триггеров — говно, а MERGE иногда работает, мягко скажем, неадекватно.
Есть алгоритм Nested Sets, вот вам его реализация на уровне триггеров.
Кому надо — используйте, кому не надо, чего рассказывать о том, что это вам не понятно сложно и вообще говно.
А не провожу никаких сравнений, а вам лишь бы хуем померяться.
Диалог совершенно неконструктивен.
> что запросы с case/if/триггеры и прочими сложными вещами напрочь сносят возможные выигрыши
Вот тут поподробней пожалуйста. Что сносит, в каких случаях и почему?
Как показывает практика, заведомое ограничение рано или поздно приводит к тому, что эти ограничения начинают существенно мешать.