Каждый сайт с обзорами продуктов имеет свой формат, систему рейтинга и классификацию.
Осталось дождаться какого-нибудь Google Markup Language как дополнение к каждому сайту, а затем, возможно, так и сами сайты станут не нужны кроме — все станут выводить в этом GoogleML и все станут ходить на одну страницу гугла :)
Охъ, есть точно такой же товарищ… Раз в неделю встревает с очередной проблемой из-за своего подхода «не думать, но делать», и просит помощи. Когда только пытаешься объяснить, что надо исправлять не в этом месте где он «подвстрял», а вообще всю структуру, огрызается, обижается и лепит очередной костыль.
Ого, при такой структуре удаление и добавление элементов будет очень медленным же. Особенно учитывая отсортированность. Изменение элемента — да, будет быстрым, но изменение кол-ва элементов приведет к пересортировке структуры.
Имелся ввиду этот пост? Я объясню почему то, что я вижу мне не нравится изначально:
Не расписана схема хранения, т.к. просто «хранение в массиве» это ни о чем не говорит: массив — структура горизонтальная, в иерархических бд вообще достигается сама иерархичность за счет определенной избыточности, благодаря которой увеличивается скорость обработки операций целыми ветвями.
массив взаимосвязанных нод — если читать дословно, то это тоже самое, что просто таблица состоящая из линка на данные, поле родителя и поле полного пути. Поясните, как именно будут строиться деревья?
Каким образом будут выполняться операции выборки/изменения ветвей?
При каких условиях(соотношение чтения/записи, объем и характер данных, глубина иерархии) ставится задача обойти mySQL?
Вообще, если тема все еще интересна, то прошу с вопросами в личку. Есть опыт работу с иерархическими базами, и возможно мог бы помочь. Но мне вполне хватает мощностей, имеющихся субд(для высоконагруженных использую оракл), которые изделиями «на коленке» не обогнать.
Eighty20 тоже очень понравилось, и даже немного удивило, что не сделали по биту на каждую букву, т.к. в «Eighty20» как раз 8 символов, и байт отображался бы полностью :)
Еще не хватает Jabber-бота, который бы отвечал на запросы по фильму, например, последние N-комментариев и их общее кол-во. Ну а если еще и рейтинг добавить… :) Если требуется помощь, готов помочь.
Структура дерева как будет храниться? Где и какие будут линки на верхний и дочерние узлы?
В том виде как расписано сейчас это вообще выходит какая-то обычная реляционная база с уникальным индексом, и доп.полем, хранящем сконкатенированные индексы родителей.
Ну-ну, если изучено, то скажите чем это лучше Cache? Зачем изобретать велосипед, в котором из функционала только руль есть, да и тот неудобный?
Пока вижу одни только минусы.
>>почему изобретаем велосипед?
>>да, скучно стало… надо освоить новые технологии.
А почему бы тогда не изучить, например, nested sets или иерархические бд? Например, Caché.
Ничего нового или особенного не увидел, и даже не увидел нормально проработанной структуры.
Осталось дождаться какого-нибудь Google Markup Language как дополнение к каждому сайту, а затем, возможно, так и сами сайты станут не нужны кроме — все станут выводить в этом GoogleML и все станут ходить на одну страницу гугла :)
Вообще, если тема все еще интересна, то прошу с вопросами в личку. Есть опыт работу с иерархическими базами, и возможно мог бы помочь. Но мне вполне хватает мощностей, имеющихся субд(для высоконагруженных использую оракл), которые изделиями «на коленке» не обогнать.
В том виде как расписано сейчас это вообще выходит какая-то обычная реляционная база с уникальным индексом, и доп.полем, хранящем сконкатенированные индексы родителей.
Пока вижу одни только минусы.
Где здесь новые технологии?
>>да, скучно стало… надо освоить новые технологии.
А почему бы тогда не изучить, например, nested sets или иерархические бд? Например, Caché.
Ничего нового или особенного не увидел, и даже не увидел нормально проработанной структуры.