Category: it

Category was added automatically. Read all entries about "it".

[йоптваю] менюшко в висте

вынь-виста.
кины всякие -- на линукс-сервере через самбу.
в эксплорере давлю ПКМ на .avi -- тормоза, тормоза, Explorer (Not Responding), тормоза бббллллядддддьььь, вылааааазит, йоптваю.

не, всё хорошо и заипца, но только вот это вот "йоптваю" -- напрягает.
так захотелось извести его, ажно мочи нет!

для начала слазил в C:\Users\<User>\AppData\Roaming\Microsoft\Windows\SendTo\ и вынес там всё к чёртовой матери: однох... моноп... инвариантно в общем.

ну лана, пошёл у гугля спрашивать. он авторитет. он всё знает.

оказалось, что нужно поставить прожко-апликушко, найти там "Video Media Properties Handler" и "Video Thumbnail Extractor" и задизейблить их всех к ебеням мышачим.

вот и нет "йоптваю"!
было, да всё вышло.

заодно и MS Groove из-под раздачи не ушёл -- ну FUD у меня на него! что и для чего не зна, а иконко глаза мозолит.
сидел бы тихонько, остался б активированным.

З.Ы. осталось вот ещё одну "йоптваю" вывести: в Файрфоксе мыше-жесты два раза иногда срабатывают.
оч напрягает, когда вместо одной закладки две (а то и три!) закрываются.
будем рыть.

PHP : Zend PHP Framework : Vaporware no more? : (continued)

как-то у себя во френдленте я наткнулся на красивое высказывание:
«Хороший программист -- это тот, кто переходя улицу с односторонним движением, всегда смотрит в обе стороны».

так вот, я искренне и ото всей души считаю, что искусство программирования по большей части состоит именно в умении смотреть в обе стороны!

в этом свете ребята из Zend'а мне представляются прямо-таки слепыми котятами, а то, что они делают, вызывает ассоциацию только с одним понятием -- абсолютный солипсизм.
для особо одарённых поясню: это когда "не существует того, о чём я не знаю".

ОК, пара примеров:

класс Zend_Feed дёргает нам фиды.
очень хорошо! просто заебательски! ах, какой хорошй и полезный класс!

говна тачанку!

во-первых, на кой хуй мне делать require_once() на обработчик Atom, если я собираюсь работать только с RSS?
та кофеварка, которая у меня работает вместо сервера -- далеко не резиновая, и память у неё очень сильно ограничена сверху!

во-вторых, я совершенно не ебу, где живут эти Zend'ята, где у них офис, и где они срут, жрут пиво и ебуццо, но одно могу сказать определённо: уж точно не на этой грешной планете!
браццы, кто-нибудь когда-нибудь пытался отпарсить несколько десятков/сотен фидов с разных сайтов? и чё, все прям были «well formed» и «correct»? да ни в хуй!
это -- Земля, браццы! Земля! на этой ебучей планетке каждое чмо так и норовит отойти от стандарта, выделиться в социуме и хоть как-то, но испоганить свой feed!

настоящий фреймворк на говно изойдёт, но выдаст на гора всю выдранную инфу из чего-угодно, хоть чем-то похожего на фид.
но только не ZPF!
на каждый чих -- ах, throw new Zend_Feed_Exception('Нет рута!'); !
ах, throw new Zend_Feed_Exception('Не могу отпарсить XML!'); !

очень программерский такой подход: "я все делаю правильно, это они не соблюдают стандарты!"
а никто не в курсе, что Клиенту, который даёт баблище за работу, совершенно на это дело посрать? ему просто поебать, чтó там, кто и как не соблюдает.
ему нужна инфа изо всех фидов. вчера! уже!

дети, блядь! хороший настоящий фреймворк в случае возникновения подобной ошибки сначала проверит наличие php_tidy и прогонит код через него.
если не получилось, проверит наличие клиентской утилиты tidy и прогонит код через неё.
если всё ещё не, поищет другие известные ему фильтраторы, очистители и т.п.
хороший фреймворк на говно изойдёт, но сделает всё (именно, ВСЁ!) возможное для того, чтобы отфильтровать весь мусор и вытащить хоть что-то из полезных данных.

а они в Zend'е работают только с UTF-8! ну ахуеть!
видимо, фиды в CP-866 им ещё не встречались.
фиды на мегабайты говна -- тоже: всё парсят только через DOM.
щисливыйе, блядь, люди!


ладно, что там у нас ещё есть?
почто!
оне отсылайут почто!
и даже держат quoted printable кодировку!

и даже сами общаются с 25-ым портом!
без посредников!
вот прямо так подсоединяются туда и чирикают с этим, блин, 25-ым портом!
уй, шайтан! валшебникинах!

а где SMTP-авторизация?
а? чё? зарифмовать?
бля! у меня -- чуть ли не с десяток уже разных почтовых экаунтов, и на всех (внимание! на всех!) -- для того, чтобы хоть чем-то пёрнуть в этот 25-ый порт, нужно сначала авторизоваться.
кто-нибудь exim настраивал? сколько там видов авторизации? угу, вот и я про то же.
а теперь угадайте, почему у меня не работает функция mail() ?..


ладно, я уже устал тут сегодня какашками кидаться налево и направо,
но у меня есть ещё одна наболевшая тема.
мы можем подняться ещё на один уровень выше, и взглянуть на этот ZPF, что называется, с высоты птичьего помёта.

я ещё вернусь...
  • Current Mood
    still bitching

PHP : Zend PHP Framework : Vaporware no more?

какой фжёпу фреймворк?! вы чо!

назвать ЭТО фреймворком мог ну разве что только совсем уже отчаявшийся поднять в этой жизни хоть какого-то баблища человек.

для начала, это -- библиотека функций, (не)множко обёрнутых в классы.
кодер пишет какой-нибудь код и использует эти функции в своей архитектуре.

сравнить с настоящим фреймворком, который исполняется всегда САМ, а кодер может только лишь перегружать некоторые методы у некоторых классов (например, как в этом вашем всеми обожаемом RoR).

ай, да! там же есть Zend_Controller?
не знаю. не видел. оно, вообще, работает? =)

а эти умилительные подчёркивания перед private и protected свойствами и методами?
ау, бля! времена РНР4 уже давно прошли!
однако ж, похоже на то, что кто-то из разработчиков тупо принёс свои старые наработки и засунул их в проект. ну как же! сроки ведь поджимают, да и добро такое жалко на мусорку выбрасывать.

а эти кучи require_once()'ов для каждого класса?
эт ж пездец! я думал, что в пятёре уже есть __autoload() и он работает вполне так ничего себе.
ну да, не без проблем, конечно же.
и наверное именно из-за них (погодите-ка! из-за собственного же долбоебизма что ли? они ж сами PHP разрабатывают!) они не решились заюзать фишку.
например, хрен ты подключишь несколько автозагрузчиков через такой механизм.
но, алилуйя!, среди разработчиков оказался хоть один действительно шарящий человек и сделал свой, дополнительный механизм -- spl_autoload().
спасибо, Маркус! from heart!

вообще, вот интересно, почему SPL включён в установку РНР по умолчанию, но нигде в ZF нет даже и намёка на то, что тот существует в природе?
наверное, SPL -- это слишком ООП?
или не стыкуется с их этой.. как её.. simplicity *сплёвывает*, во!
ну, хуй его знает, наверное были у них на то свои причины.

про кучу "TODO" в коде я уж и не говорю даже.
сырость такая, что можно уже начинать разработку залежей пенницилина со всей этой плесени.
если вам, ребяты, всё ещё надо столько сделать, то на кой хуйъ вы зарелизились сейчас, а не через два года?
ах, да! release early, release often *сплёвывает*!..
ну а чё тогда только сейчас созрели с пре-релизом?
выкладывали бы сразу, после каждой написанной строчки, вместо того, чтобы весь этот hype раздувать.
имбецилизм, бля!

но что это я по мелочам всё придираюсь, ко всяким там подчёркиваниям доёбываюсь?
взрослые ж люди всё-таки! надо подняться уровнем повыше и взглянуть на всё это ещё разок!
точно!

ну, значит я ещё вернусь...
  • Current Mood
    bitching

spam attack : mail inject

судя по всему, совсем скоро во всяких рассылках по безопасности, а особенно про PHP, появится новая тема, которая встанет рядом с SQL-inject'ами: Mail-injects.

ситуация:
сайт.
веб-форма, где юзер должен зарегаться.
после заполнения данных, юзеру высылается мыл активации: "нажмите линк, чтобы подтвердить... бла-бла-бла".

проблема:
мыл высылается на адрес, указанный юзером в форме.
большие дяди-программеры, уже наученные горьким опытом, всяко будут фильтровать пришедшие данные на предмет кавычек, слэшей и всякой прочей поебени: юзерский мыл ведь нужно зарегать в базе и всё такое.
отсылка производится как-то типа:

mail(
    $filteredUserEmail,
    $mailSubject,
    $mailBody,
    "From: no-reply@huemae.com"
);


и что же делают наши всеми горячо любимые сцуко-пилять-спамеры-я-их-мама-ибаль?
они поступают очень просто: засовывают в поле "Ваш мыл" что-то типа вот такого:

$userEmail = "bleh@fokya.com\nCc: pepe@aol.com; paco@terra.es; puto@gilipollas.com";


доверчивый и наивный РНР не делает никакой магии с параметрами, полученными в mail().
он тупо формирует заголовки мыла и настолько же тупо и прямолинейно отдаёт их MTA, который совершенно честно и откровенно, получив вот такое:
Subject: Please, confirm
From: bleh@fokya.com
Cc: pepe@aol.com; paco@terra.es; puto@gilipollas.com
Content-type: text/html

...рассылает теперь спам от имени сайта, копируя каждый мыл ещё на десятки экаунтов.

да, в теле сообщения может быть какой-нибудь мусор с точки зрения сцуко-пилять-спамеров-я-их-мама-ибаль, типа "нажмите на этот линк, чтобы подтвердить...", однако ведь есть кучи скриптов, которые лишь формируют красивую HTML-табличку, сплошь состоящую из только что введённых юзером данных и ничего более.

бедный AOL-user теперь получит по мылу табличку от имени моего сайта, в каждой строчке которой будет: "хуй два метра нахаляву прямо щас!", не устоит от соблазна и станет очередной жертвой интернет-мошенников.

от така хуйня, малята!
научившись фильтровать данные для SQL, нехуй останавливаться на достигнутом: теперь можно переходить к мыл-адресам.
а сцуко-пилять-спамеров-я-их-мама-ибаль -- мочить!

PHP sourcecode encoding : RIP

чего и следовало ожидать, декодер для Zend SafeGuard Suite появился.

хрень, хоть и через пень-колоду, но таки работает.

я теперь не знаю ни одного инструмента, которым можно б было относительно надёжно скрывать исходники РНР.
опенсорц побеждает?

UPD: ах, да! кажется, декодирует пока только PHP4.

PHP5 : getters and setters

наблюдаючи за одним топиком в PHPClub'e...

откуда ж, блин, пошла эта догма о том, что "всегда-всегда-всегда нужно использовать геттеры и сеттеры"?
действительно ли это настолько правильно и нужно в PHP?

в некоторых языках типа Delphi, C#, Flash AS2 и др. встроена поддержка Свойств на уровне языка, которые там так и называются: Properties.
используя эти Свойства, мы можем по мере надобности "подвешивать" методы-обработчики как на чтение, так и на запись значения какого-либо свойства класса.
таким образом, в работе с объектами всегда используются прямые вызовы к свойствам, а вызывать какой-нибудь метод при этом или сразу же пихать значение куда надо, решает только сам класс.

но есть и "ущербные" в этом плане языки типа, например, Java, где геттеры и сеттеры -- практически единственный выход из ситуации.
учитывая подавляющую распространённость Джавы, неудивительно, что у многих программеров создаётся неверный стереотип, что без геттеров и сеттеров ну-совсем-никак-иначе-пиздец.

к какому типу языков отнесём РНР?

рассмотрим код:

<?php

class A
{
    public
$prop;
}

$a = new A;
$a->prop = 5;

?>


как бы мы сделали его "чиста па панятиям", т.е. через геттеры/сеттеры?
думаю, что где-то вот так:

<?php

class A
{
    protected
$prop;

    function
getProp() { return $this->prop; }
    function
setProp($value) { return ($this->prop = $value); }
}

$a = new A;
$a->setProp(5);

?>


фунах! мне уже не нравится этот код!
зачем я буду "раздувать" класс методами в количестве (N*2) штук (где N -- кол-во свойств), из которых мне действительно понадобится лишь небольшая часть?
ну ладно, тогда сделаем так:

<?php

class A
{
    protected
$Prop;
    protected
$AnotherProp;

    function
__call($method, $params)
    {
        if(
'get' === ($method3 = strtolower(substr($method, 0, 3))))
        {
            
$name = substr($method, 3);
            return
$this->$name;
        }
        if(
'set' === $method3)
        {
            
$name = substr($method, 3);
            
$this->$name = array_shift($params);
        }
    }
}

$a = new A;
$a->setProp(5);
$a->setAnotherProp(10);

?>


тут я должен воскликнуть: "охуеть!", - что в переводе должно означать не иначе как: "hmm, that's too much magic!"
к тому же, мне совершенно не нравится использовать методы там, где я бы заюзал обычное присваивание.
попробую-ка таки вернуться к столь приятному мне присваиванию, но и в то же время не потерять нужного функционала:

<?php

class A
{
    protected
$_prop;
    protected
$_anotherProp;

    function
__get($name)
    {
        
$method = 'get'.ucfirst($name);
        return
method_exists($this, $method)
            ?
$this->$method()
            :
$this->{'_'.$name};
    }

    function
__set($name, $value)
    {
        
$method = 'set'.ucfirst($name);
        if(
method_exists($this, $method)) $this->$method($value);
        else
$this->{'_'.$name} = $value;
    }

    function
setAnotherProp($value)
    {
        throw new
Exception("AnotherProp is read-only!");
    }
}

try
{
    
$a = new A;
    
$a->prop = 5;
    
$a->anotherProp = 10;
}
catch (
Exception $E) {}

?>


вах, шайтан!
что же это получилось-то?
а получилось то, что геттеры и сеттеры мы можем навешивать лишь тогда, когда это действительно нужно.
получилось, что класс сам автоматически будет вызывать геттер или сеттер в том случае, если он существует.
также получилось, что "клиентский код" совершенно не изменился: мы всё также используем красивое (эстетически, угу) присваивание к свойству, а не вызов метода.

так нужны ли геттеры/сеттеры в РНР всегда-всегда-всегда?
вопрос риторический.

FAR + Colorer (continued)

в то время, когда основная работа не идёт совсем никак, нужно как-то отдыхать.
гонять до полного охуевания игрушки или начинать очередной "запой" на 3-5 книжек фантастики подряд что-то не очень хочется.

попробовал отдыхать, не выходя из темы, а лишь немного сменив контекст:
сделал поддежку PHP5 в подсветке синтаксиса для редактора FAR'а.

в этот раз time estimation почти получилось: отвёл себе 3 часа и управился за 4:
- слить phpdoc из CVS
- написать парсер нужных файлов, чтобы вытащить из них нужное
- сгенерить HRC-файлы в правильном формате

всё получилось как надо, и тут, как всгеда бывает в таких случаях,
ударила... просто-таки йобнула моча в голову: захотелось ещё и phpDocumentor'а в комментах.
хули ж!.. раз уж начал-то... давай сделаем!.. ведь круто ж будет!..
...пéздолочь бля!

убил в общей сложности где-то 6-7 часов, мучался как хуй, пока кое-как с горем пополам разобрался во всех этих HRC'шных наворотах, но всё-таки добил: теперь все тэги phpDocumentor'a маркируются как надо.

итог: никакого отдыха. сижу выжатый ментально как лимон.
наверное старый уже становлюсь для такой хуйни.

мораль: перфекционизм -- давить!
это -- тяжёлое психическое заболевание, от которого одни только неприятности.
но оно пока сильнее меня... =(

качать: Colorer-take5-PHP5.tar.gz (48K; распаковать в C:\Program Files\Far\Plugins\)
  • Current Music
    S.U.N. Project - [Macrophage #06] Sexdrugs & Acidtrance II

SQL Trees (finished)

ладно, кажется мои "страсти по деревьям" подходят к завершению.
с механизмом я вроде бы определился, и окончательный выбор меня на самом деле немало удивил.
попробую обобщить здесь накопившуюся инфу о проведённых тестах.

чтоб не было потом лишнего пиздежа:
<disclaimer>
все нижеприведённые тесты некорректны априори!
сравнивались разные механизмы на двух совершенно разных СУБД, которые несравнимы.
единственное, что совпадало -- набор данных и структура дерева.
так или иначе, тесты я делал для себя, нужную мне информацию я получил, а всё остальное -- фпесду и ниибёт.
если появятся злоебучие крохоборы и борцы за Вселенскую Правду™, буду говорить лишь: "OMG STFU, don't bitch and get a life, dork!"
</disclaimer>

целью данных тестов было найти подходящий механизм хранения и обработки информации, структурированной в виде дерева, в СУБД PostgreSQL. механизм должен работать приемлемо быстро (кто как хочет, так и интерпретирует это определение) на деревьях в несколько тысяч нод, а также должен быть достаточно удобным на момент изменения содержимого дерева.

ладно, прежде всего -- общая картина -- графики с результатами. помимо обычного, привожу график с логарифмической шкалой, чтобы лучше была видна разница:


INSERT PATH
DESCENDANTS DELETE
вот так расположены графики следующих тестов:


INSERT - вставить необходимое кол-во нод в дерево.
набор данных и структура генерируются случайным образом однажды в самом начале тестов. поле "полезной нагрузки" в отдельной таблице лишь одно и содержит текст "node<N>", где <N> -- порядковый номер ноды.

PATH - для каждой ноды дерева получить её "путь" до корня дерева.

DESCENDANTS - для каждой ноды первого уровня получить всех её потомков.

DELETE - последовательно удалять каждую ноду первого уровня вместе со всеми её потомками.

вот теперь -- самое вкусное: описания графиков различных механизмов. хотя, описанием это назвать будет трудно, поэтому наверное лучше таки использовать термин обоснование.
гы, будет смешно, если потом окажется, что в тестах были грубые ошибки, и придётся точно так же всё обосновывать на противоположное. =)


ADJ-M - Adjacency List (MySQL)
несомненно, самый быстрый механизм.

на операции INSERT он просто таки уделывает всех конкурентов, т.к. мы тупо загоняем записи в дерево, лишь указывая каждой записи её прямого предка.
в таблице структуры обновляется лишь индекс по предкам.

на операции PATH уже даёт себя знать геморрой в коде, т.к. для каждого уровня мы должны сделать отдельный запрос:

SELECT nod_id FROM tree WHERE nod_id = ?nod_parent


и тем не менее, разница по PATH с другими механизмами на MySQL исчезающе мала!
всё это потому, что MySQL прямо таки резок как понос на простейших выборках по PRIMARY KEY и сделает на них любую другую "взрослую" СУБД.

операция DESCENDANTS, которую можно в некотором роде считать обратной операции PATH, тоже наблюдается охуенная скорострельность, даже несмотря на рекурсию, к которой приходится прибегать. хотя, сознаюсь, у меня в тесте был лишь один цикл, а не рекурсия, что наверное децл ускорило выборку. так или иначе, эта операция совершенно не выбивается из ряда других механизмов на MySQL.

на DELETE все остальные немножко обосрались по сравнению с ADJ-M, даже несмотря на то, что удаление шло в две стадии -- точно так же, как и выборка в DESCENDANTS -- сначала получить список нод, а потом уже их удалить.


NST-M - Nested Sets (MySQL)
очень хороший механизм! прямо таки самый-самый, если не брать во внимание жутчайшие тормоза на операции INSERT, где время работы растёт экспоненциально.

INSERT: пиздец-какие-тормоза! ноу комментс.
PATH: супер быстро. быстрее работает только RAL-M, потому что там запросы проще.
DESCENDANTS: круче нас тока йайца! выборка по уникальному индексу -- что может быть быстрее.
DELETE: то же, что и в DESCENDANTS -- очень даже хорошо


RAL-M - Redundant Adjacency List (MySQL)
механизм такой же, как и ADJ-M, только в таблице со структурой дерева храним ссылки не только на прямого потомка ноды, но и на всех её потомков.

хороший механизм, и работает даже быстро. графики комментить не буду, но лишь замечу, что на тестах с большим кол-вом нод в дереве под PostgreSQL он получается просто пиздец каким избыточным, давая сильнейшие тормоза.


RAL-P - Redundant Adjacency List (PgSQL)
ADJ-P - Adjacecncy List (PgSQL)
да-да, я там наебался маленько в агенде к графикам. то, что обозначено RAL-P следует читать как ADJ-P (потом может быть поменяю, сейчас не могу). почему я отказался от RAL-P я уже пояснил в предыдущем параграфе.

итак, переходим на другую платформу -- PostgreSQL, для которой всё и делается.
теперь в БД я усиленно использую хранимые процедуры и триггеры, ессно постоянно думая о скорости работы, но и давая себе отчёт в том, что все эти фишки так или иначе будут тормознее, чем голый король MySQL.
важно: дефолтный конфиг PostgreSQL я поменял, выдав ему то ли 64М, то ли 128М памяти для работы. то, что ему даётся по умолчанию -- просто смешно.

ADJ-P показал себя на самом деле просто суперски.

INSERT: линейный рост и скорость сравнима с ADJ-M, хотя на каждое добавление ноды идёт один лишний SELECT (получить кол-во существующих детей у родителя) и UPDATE (инкремент счётчика детей для родителя). это делается потому, что SELECT COUNT(*) в PostgreSQL сканирует всю таблицу (сравнить с MySQL, где эти данные берутся напрямую из дескриптора таблицы), поэтому получается дешевле поддерживать этот счётчик во время работы, чем пересчитывать его каждый раз по мере надобности.

PATH: да, пришлось реализовать рекурсию на процедуре, и выборка пути теперь производится красиво:

SELECT nod_id FROM path_of(?nod_parent)


...но даже вместе с этим, по скорости мы несильно выбиваемся из ряда графиков, полученных на быстром MySQL.

DESCENDANTS: тормоза-тормоза! но зато хоть рост практически линейный, да и выборка идёт с помощью рекурсии в хранимой процедуре, как это сделано в PATH, что очень и очень удобно для клиентского кода.

DELETE: в клиентском коде опять сплошные удобства -- удаляем только одну запись, а об остальном позаботится FOREIGN KEY. небыстро, но всё ж лучше, чем...


INT-P Nested Intervals
да, у меня получилось таки имплементировать Вложенные Интервалы. ну и поеботень же!
теория красива донельзя: смесь Nested Sets и Redundant Adjacency List, всё хранится в двух целых числах.
проблемы вылазят лишь на момент жёсткого использования механизма.

прежде всего, ограничение на кол-во нод в дереве. числа растут неприемлемо быстро, и обычного INT'а начинает нехватать, а переход на BIGINT, боюсь, ещё более затормозит, да и всё равно проблемы это не решит.

к тому же выборки потомков и предков производятся либо по функции с двумя умножениями и одним вычитанием (что жутко грузит процессор и дико тормозит), либо по числам с плавающей точкой (что не гарантирует точность).

результаты теста привёл для истории, но комментировать эту порнографию, везде возрастающую экспоненциально, совершенно не хочется.



в заключение только скажу, что я выбрал ADJ-P, т.к. всё остальное либо неудобно, либо тормозит. добавлю ещё пару хранимых процедур, чтобы максимально облегчить себе работу с кодом на стороне клиента, и будет мне щасье.

SQL Trees (continued)

продолжаем Страсти по Деревьям.

RAL -- это моё собственное название, обозначающее Redundant Adjacency List.
это когда для кажой ноды дерева хранится ссылка не только на её непосредственного родителя, но и на всех остальных её родителей.

т.о., для ноды 1.3.5.12 в таблице со структурой дерева будут храниться записи (1.3.5.12 - 1.3.5), (1.3.5.12 - 1.3), (1.3.5.12 - 1).
избыточно, да, но зато можно легко одним запросом получить, скажем, всех потомков ноды, или вычислить путь от ноды до корня дерева, и даже... реализовать множественное наследование.

но не всё ладно в датском королевстве, ибо без хуйни нельзя никак, а потому она всегда случается.

PostgreSQL 7.4 CygWin, леплю триггеры, оптимизирую таблицы и все запросы, чтобы было Как Надо™, добавляю 100К нод в дерево, случайным образом выбирая предка.

запустил скрипт утром, а после обеда оно как раз дошло до магического числа "фу-у, заебало!", которое по историческо-астрономическо-волшебным причинам всегда равняется в точности ("дохуя" / 2).
в общем, нажал я ^C, и...

добавилось 51 715 нод. (всего-то?!)
наибольшее кол-во нод "падало" в среднем на уровни с 9 по 13.
всего уровней в дереве получилось 25.
кол-во связей между нодами -- 580 847 (хуяссе!)
две таблички с этим деревом заняли на диске ~160М

и тем не менее, мне всё ещё нравится эта схема устройства дерева:
на вставке хоть и тормозит, но тормозит меньше, чем Вложенные Множества, зато на выборке инфы бегает резво.

выводы пока оставлю на потом...
может таки удастся ещё что-нибудь там соптимизировать.

SQL Trees

Adjacency List, Nested Sets, Redundant Adjacency List, Nested Intervals...
первое, браццы, только первое! всё остальное -- полнейшая хуйня.
*нервно хихикает и бьётся в истерике*

З.Ы. потом перепроверю. оч надеюсь, что найду огромную ошибку, тогда уж спокойно назову себя дебилом и продолжу. а пока -- чё-то ваще пиздец.
  • Current Mood
    emotionaly unstable