Добавить комментарий

Изображение пользователя ipanshin.

написанное из письма

Прочитал и, если все это правильно (а мне нет причин не доверять написанному), то все это ужасно и говорит о том, что Библия права и техническое общество идет по пути регресса также. Либо, как говорили адепты государства: "Повторенье - мат ученья". А также "Мат-природа". Про отца они почему-то молчат. Либо отец просто неизвестен. Я к этому также не имею никакого отношения.

Какой-то феерический туман
Людей стремящихся вокруг
Их фонарей смешной обман
В твой освещенный круг...

В силу своей лени скопипастил написанное из письма (письмо писал я же, но раньше). Думаю, что в пику теме.

Я тут прочитал наконец-то на выходных статью, которая меня заинтересовала
http://queue.acm.org/detail.cfm?id=1961297
в надежде все-таки уяснить себе, что предлагают нового в подходе nosql.

До этого момента
!(a && b) == (!a)||(!b)
!(a||b) == (!a)&&(!b)
все вроде было нормально. Всякие там PK-FK для SQL и LINq для nosql.

Я все-таки кое что помню из логики высказываний и понимаю, что правила деМоргана основываются на том что пара логических функций & and ! или V and ! являются ортогональным базисом, иначе говоря любую логическую функцию можно представить в этих базисах. В первом случе мы получаем коньюнктивную форму, во втором - дизъюнктивную.
Авторы статьи почемуто это все называют duality (Examples of duality abound in computer science.) и говорят, что такого "дуализма" много и в конечном итоге переходят к паре sql - nosql. Это что доказательство или заказная статья?

Опять же из того, что я помню с тех времен, когда SQL движков не было. Да, тогда просто брались и создавались структуры в рамках работы некоторого приложения. Далее оказалось, что этот путь очень трудоемок в плане интеграции данных и был придуман интерпретирующий подход доступа к данным. В районе 70-80 годов был написан интерпретатор языка sql, который брал задачи структурирования информации (insert,delete,update,select) на себя.

Дело не в том, что sql подразумевает использование пар PrimaryKey-ForeignKey, а в том, что реализация его - это интерпретатор, что для призводительности - нож, зато для сложности - благо. Разбиение сложной задачи доступа к данным из приложения разбивалась на две более простых части.

В рамках подхода nosql, как я понял, прежде всего выкидывается sql-интерпретатор и используются linq конструкции в самом приложении. Чем собственно говоря я и могу пользоваться в рамках C# проекта. Это работает до момента, пока не оканчивается оперативная память. После этого все начинает либо тормозить, либо разваливается.
А как же тогда решается задача интеграции данных между приложениями? Никаким другим путем кроме как выгрузки DDL and DML информации в обычные текстовые файлы мне в голову не приходит. Именно отсюда и вырос xml. Так? Если это так, то в 70-80 годах - это была отправной точкой прихода к sql-интерпретатору.

Мы уже видим потери такого подхода, заключающиеся в необязательности транзакционных механизмов и частичной потери данных в резалтсетах. Какая ерунда, что пара строк потерялась? Ведь чтото вы получили?

Вот такие размышления.