для этого в jquery есть метод live

Не понял, при чем тут он.

если вашу ссылку с якорем просто вставить в адресную строку браузера, то она не сработает. (если правильно понял)

в данном варианте — нет

не понял вопросов, если честно
context задает получателя AJAX-событий

>Нет начальной инициализации страницы.
Она не нужна, если первое попадание идет на index page

мы — нет

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

а были какие-то численные оценки, сколько серверных ресурсов жрет RTMP сравнительно с HTTP?

Можно. Конкретно в том проекте, где мы это делали, ресайз как отдельная ступень не применялся, в основном потому, что цепочка трансформации была довольно сложная. Однако если форматов много, отдельный ресайз может иметь право на жизнь.

У нас были большие проблемы с WMV. Что касается wowza, то отзывы по ней не всегда хорошие, но прежде всего из-за плохого «customization».

> На низком уровне данные хранятся в Б-деревьях — уже давно во многих крупных СУБД (тот же оракл).

Ого. Прямо-таки все данные и прямо в Б-деревьях? Б-дерево не самый удачный формат при большом объеме данных.

> Для дерева и куба операция поворота тривиальна — модно укладывать одни данные в столбик, а другие в строку

Операция, наверное, тривиальна, только с компрессией данных, боюсь, будут проблемы )))

Мне кажется, гибридное решение Oracle более-менее все эти нужды покрывает. Можно создавать compression unit, можно классические таблицы, можно materialized view. Думаю, в будущем все вендоры внедрят вертикальную схему (как опцию), хотя на это уйдет лет 5, наверное.

SQL не супер-удачный язык, но вряд ли он умрет в ближайшем будущем — альтернативы ему нет. Стоунбрейкер это прекрасно понимает и свой движок C-Store он делает как SQL-базу.

Что касается революции, то я думаю, что ее не будет. Реляционные СУБД живут уже не один десяток лет и проживут еще долго. А вот сколько видов СУБД уже накрылось — не счесть. Навигационные (типа ISAM), сетевые, объектные…

Если под организацией данных понимается способ их хранения, то да.

Нет, не надо :)

Простая комбинаторика говорит о том, что данные, разрезанные по столбцам, сжимаются всегда лучше тех же данных, упакованных в одну строку :) или будет формально правильнее сказать «не хуже»

я так не думаю, это тупо зависит от объема данных, который надо прочесть и от их фрагментации

Сжатие данных как бы не ради пропускной способности делается.

О как. Ну, возможно в SQL Server это делается ради экономии места на диске стоимостью $500, однако в таких базах как KDB или Vertica компрессия данных является ключевым функционалом, влияющим на пропускную способность СУБД (в том числе за счет более «плотного» заполнения кэша, а также возможности фильтрации сжатых данных). :)

Медленно или медленнее? Скан по сжатым данным и по одной колонке всегда быстрее, чем по всем колонкам.

Касаемо индексов, если интересно, можно почитать, как они устроены в C-Store: C-Store: A Column-oriented DBMS. Там есть понятие Projection, которое приблизительно эквивалентно Materialized View с кластерным индексом. (Projection может быть отсортирован)

Я не работал много с SQL Server, но судя по описанию его Page Level Compression работает только в пределах страницы и ухудшается при добавлении колонок в таблицу (т.к. при этом все меньше кортежей будет попадать в страницу).

Поэтому с большой вероятностью (тут, конечно, нужны тесты) описанный набор данных при колоночном хранении будет сжиматься гораздо лучше. Кроме того, интересно будет узнать, как это повлияло на пропускную способность SQL Server. В случае DB2 row compression, например, результат не так впечатляет:
When running our DSS workload (consisting of complex queries) a 6% throughput
improvement was observed in the single stream case when using row compression.

Компрессия в MS SQL и вообще компрессия в традиционных СУБД вряд ли делает погоду. Другое дело — если используется гибридное хранение данных, т.е. «объединив колонки» на физическом уровне. Делает ли это MS SQL — не знаю.

>можно вынести часто необходимые данные отдельно от таблицы
Это уже будет дублирование данных. По поводу секционирования по строкам — думаю, большинство вертикальных движков это решают даже лучше путем сортировки данных в колонках.

так никто и не спорит.
Если бы вертикальные СУБД были лучше для всех, то все базы давно бы переделали в вертикальные.

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

Сжатие, безусловно, есть. И даже в DB2 пятилетней давности оно было. Но максимально эффективно сжать можно только разделив данные на колонки. Грубо говоря, чем больше разнородных данных мы пытаемся сжать, тем хуже они будут сжиматься.

А как индексы позволяют секционировать ДАННЫЕ?