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