Обращаю внимание на то, что Вы ещё не приводили «чётких примеров и дефиниций», равно как и ссылок на публикации по брейнетике.
Тем не менее, приведу несколько ссылокпросемиотику. Их более чем достаточно для понимания концепции представления знаний. Сенсформика и индефинитика представляют меньший интерес для данной темы.
Если отвечая на мой первый вопрос выше, Вы скажете «да», это означает, что знания, содержащиеся в сообщении «Петя сказал, что завтра он не пойдёт в школу» могут быть сохранены в любой современной БД. Если же ответ «нет», то рассуждать нужно не о «матрёшечной» структуре, а хотя бы о базовой реализации БЗ на самом примитивном уровне (раз уж он, на Ваш взгляд, качественно отличается).
В целом, не конструктивно предлагать дискуссию о знаниях столь туманно описывая проблематику и не ссылаясь ни на какие публикации. Спекулировать на фундаментальных проблемах не предлагая новых теорий или методов, критикуя всех и вся — удел псевдонаук.
Для меня такае науки, как семиотика, сенсформика и индефинитика дают достаточное понимание о том, как можно представлять и обрабатывать знания. А такие стандарты (RDF, OWL, micro*) или онтологии (такие, как SIOC, SKOS, DC, FOAF) являются отличными инструментами для того, чтобы воплощать это в жизнь.
Т.е. Ваша точка зрения заключается в том, что для перехода от данных к знаниям необходимо увеличить детализацию самих данных, их контекста и учесть некоторый набор типовых поведенческих, мыслительных алгоритмов человека?
О какой вложенности идёт речь, можно больше конкретики? Описанная вложенность — алгоритмическая, она не отражается на представлении знаний.
Перечисленные типы БД не обладают качественными различиями в контексте обсуждения. Вложенность можно реализовать используя любой из обозначенных подходов, равно как перевод данных из однго представления в другое не представляет сложностей (это лишь дело удобства и быстродействия обработки данных).
Благодаря сообществам, сделанное одиночками приобретает значимость, обретает поддержку/финансирование/и т.п. Но сам факт того, что фундаментальные проекты в области ИТ сделаны теми самыми одиночками, от этого не меняется.
Не забывайте, что вероятность получения worst case для массива уже из 100 чисел составляет менее 10^-200 при более-менее нормальной реализации алгоритма. Поэтому для быстрой сортировки используется оценка средней сложности, которая как раз составляет O(n log n).
Аналогии были про накладные расходы для обеспечения изменения поля в зависимости от его значения и без этой зависимости. Апдейтом можно изменить счётчик на 10%, а INCR — нет. За счёт такого ограничения удаётся избежать создания блокировок на уровне строк в БД. Как это реализовано на уровне ядра СУБД, думаю, можно узнать у хабраюзера kadishmal. Мне кажется, это вариация на тему атомиков.
Для вознокновения дедлока необходимо как минимум наличие блокировок.
Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…
Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).
Второй вариант. INCR предполагает что у нас есть стопка карточек со всеми возможными номерами, а каждая операция лишь сбрасывает верхнюю карту.
В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).
Думаю детали реализации можно подсмотреть — проект же открытый :)
Соглашусь про нелогичность операции «чтения» которая меняет данные, это сродни геттеру, который меняет поле класса при каждом вызове. UPDATE RETURNING всё же не является эквивалентом именно из-за создания блокировки. Тем не менее, рост производительности пытается всё это оправдать :)
Насколько я понял коммиты для такой экзотики не нужны, равно как и роллбэки, которые просто не будут работать.
С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
Люди читающие заметку хотят знать чем она может быть полезна им, а не Вам, при всём уважении. Я не отрицаю актуальность решённой проблемы, а лишь хочу чтобы она была ясна до прочтения стены комментариев.
Обратите внимание на количество сделанных вами оговорок: «требуется именно имитировать ajax-клиента», «кросс-доменный запрос», «все лагает, памяти на всех не напасешься», кроссплатформенность и т.д.
Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
и, в завершение ликбеза по man'у -H "content-type: application/soap+xml"
-b "some cookies"
В любом случае, предположение об отсутствии «приличного инструмента для отладки json» сомнительно.
Тем не менее, приведу несколько ссылок про семиотику. Их более чем достаточно для понимания концепции представления знаний. Сенсформика и индефинитика представляют меньший интерес для данной темы.
Если отвечая на мой первый вопрос выше, Вы скажете «да», это означает, что знания, содержащиеся в сообщении «Петя сказал, что завтра он не пойдёт в школу» могут быть сохранены в любой современной БД. Если же ответ «нет», то рассуждать нужно не о «матрёшечной» структуре, а хотя бы о базовой реализации БЗ на самом примитивном уровне (раз уж он, на Ваш взгляд, качественно отличается).
В целом, не конструктивно предлагать дискуссию о знаниях столь туманно описывая проблематику и не ссылаясь ни на какие публикации. Спекулировать на фундаментальных проблемах не предлагая новых теорий или методов, критикуя всех и вся — удел псевдонаук.
Для меня такае науки, как семиотика, сенсформика и индефинитика дают достаточное понимание о том, как можно представлять и обрабатывать знания. А такие стандарты (RDF, OWL, micro*) или онтологии (такие, как SIOC, SKOS, DC, FOAF) являются отличными инструментами для того, чтобы воплощать это в жизнь.
О какой вложенности идёт речь, можно больше конкретики? Описанная вложенность — алгоритмическая, она не отражается на представлении знаний.
Перечисленные типы БД не обладают качественными различиями в контексте обсуждения. Вложенность можно реализовать используя любой из обозначенных подходов, равно как перевод данных из однго представления в другое не представляет сложностей (это лишь дело удобства и быстродействия обработки данных).
Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…
Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).
Второй вариант. INCR предполагает что у нас есть стопка карточек со всеми возможными номерами, а каждая операция лишь сбрасывает верхнюю карту.
В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).
Думаю детали реализации можно подсмотреть — проект же открытый :)
Насколько я понял коммиты для такой экзотики не нужны, равно как и роллбэки, которые просто не будут работать.
С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
P.S.: сама статья понравилась.
Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
-H "content-type: application/soap+xml"-b "some cookies"
В любом случае, предположение об отсутствии «приличного инструмента для отладки json» сомнительно.
curl -d @request_file.xml "url string here"в android market тоже пока что недоступно
не иначе как для Франкенштейна