KaraNagai говорит гадости об SQL

[tadpole]

Сообщение от KaraNagai

офф: каранагай и про SQL уже лет 12-13 говорит подобные же гадости, кстати.

А можно подробнее? Правда интересно.

[YellowMan]

Да это на него университетская среда так сказывается - им бы не учиться пользоваться тем что есть а поломать бы все и новое изобрести

Речь насколько я помню шла о релативной модели хранения данных в современном мире и стандарте СКЛ как его инкарнации.

[KaraNagai]

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

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

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

Я сам тоже чисто с эстетической точки зрения. Хотя конечно принцип "красивый самолёт хорошо летает" мне отчасти близок

[tadpole]

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

Но вот интересно - а какие есть / могут быть альтернативы? Данные надо хранить и обрабатывать, это очевидно. Писать под каждое приложение свою СУБД неэффективно со всех точек зрения. Объектные БД попытались многие делать и бросили это дело...

[YellowMan]

Ты не лезь своими ООП лапами в наш чудный релативный мирок - если что и выдумано и высасано из...ну пусть будет - из пальца так это ваше ООП

YellowMan добавил 02.09.2008 в 15:30

Данные надо хранить и обрабатывать, это очевидно.

я бы сказал что ключевое тут - данные надо описывать. Другими словами переносить несовершенность мира в математическую гармонию.
ИМХО, релативная модель намного объектно-ориентирована чем самый объектно-ориентированный язык.
Есть объект, у него есть свойства и взаимодействия с окружающими объектами - все это чудно описывается в СУБД.

[KaraNagai]

Данные надо хранить и обрабатывать, это очевидно

Очевидно. Хотя есть мнение, что разделение на RAM и Storage - искусственно и надо хранить полное состояние системы и единственным средствам доступа к этому состоянию должен быть её API.

Объектные БД попытались многие делать и бросили это дело...

Ну дык говорю ж непросто. Опять же не следует забывать о том, что изначально негативный опыт с ООБД накопленный во времена, когда ни требования ни возможности современного уровня не были доступны, играет подавляющую роль в отношении развития этих идей.

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

Помимо ОО-модели есть ещё всякие модели основанные на тех или иных предикатных исчислениях и т.п.

Это за реляционку. А вот над альтернативами SQL народ ведь работает. От SQL отказаться куда легче, чем от реляционной модели вцелом.

Есть объект, у него есть свойства и взаимодействия с окружающими объектами - все это чудно описывается в СУБД.

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

Я согласен что ОО-представление - это упрощение. Но это упрощение естественное. Основанное на одном простом свойстве мозга - находить подобие между предметами и явлениями и порождать стереотипы. Табличное же представление - есть сугубо следствие развития IT на его начальном этапе. Сиречь - следствие уже давно несуществующих технологических ограничений.

[Ludwig]

Сообщение от tadpole

Но вот интересно - а какие есть / могут быть альтернативы? Данные надо хранить и обрабатывать, это очевидно. Писать под каждое приложение свою СУБД неэффективно со всех точек зрения. Объектные БД попытались многие делать и бросили это дело...

Предположим в неком языке X можно написать что-то вроде:

class Customer
{
    string name;
    // ...
}

class Order
{
    Customer who;
    Date when;
    Item what;
    // ...
}

persistent Customer customers[];
persistent Order orders[];

// и далее где-то в коде:

function getAllOrdersFor(Customer c) {
    Order result[];
    foreach (o in orders) {
        if (o.who == c)
            result[] = o;
    }
    return result;
    // можно было написать короче с помощью reduce(), но не важно
}

В принципе нормальная программа с обычной логикой, если только забыть об этих директивах persistent. Но вот они-то и заставляют компилятор разместить эти два массива в persistent storage преобразовывать все обращения к ним в запросы, возможно с использованием индексации итд. Но все это прозрачно для программиста. Числовые поля ID и реляции генерируются автоматом, как замена указателям в ран-тайм.

Возможно ли такое? Вроде да. Чапай думает над проблемой Будут ли программисты счастливы и эстетически удовлетворены с таким языком? Думаю big time.

MS пытается что-то там сделать с ихним LINQ, но это не то, вроде мне показалось что существенно слабее.

P.S. конечно можно было бы не возврашать массив, а делать что-то на ходу, например выводить в HTTP, не важно.

[YellowMan]

Речь ИМХО о замене табличной РСУБД объектной СУБД.

Реализация не особо важна - важен новый принцип и доходы от него. Я честно говоря не вижу чем бы ОСУБД будет лучше РСУБД.

[tadpole]

Сообщение от Ludwig

Предположим в неком языке X можно написать что-то вроде:

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

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

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

[Ludwig]

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

Дело в том, что все Тьюринг-полные языки взаимно-транслируемы, а SQL - он даже подмножество Тьюринг-машины. Имей ввиду, что SQL так или иначе транслируется в какой-то код - нативный или псевдо - не важно, а значит точно такой же код можно получить из другого языка. Из Тьюринг-полного языка это даже гарантируется. Вопрос только в том, чтобы сделать это хорошо.

Ну что, и в GCC не в один день был построен то есть вся магия оптимизации не сразу делалась.

Проблема с SQL в том, что он дает иллюзию контроля над данными, и поэтому отказ от SQL кажется чем-то страшным и даже невозможным. Но ведь SQL - это всего-лишь жалкая недо-Тьюринг-машина, только и всего!

[tadpole]

Сообщение от Ludwig

tadpole, подойдет к любой задаче на самом деле.

Возможно. Не верю, но возможно Поверю, когда увижу своими очкастыми глазами.

[YellowMan]

Ну опять не то - СКЛ всего лишь механизм доступа к данным, твой интерфейс к реляционной модели.
Модель же - не язык а набор правил описывающих данные, их взаимосвязи и отношения к внешним раздражителям.

Другими словами - язык может быть любой, модель - реляционная.

[tadpole]

Сообщение от YellowMan

Модель же - не язык а набор правил описывающих данные, их взаимосвязи и отношения к внешним раздражителям.

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

[YellowMan]

Это совершенно разные вещи - язык программирования и модель хранения данных.
Они как-бы совершенно не пересекаются.

Пирамида как-бы такая:

Реляционная модель --> Имплементация (версионная или блокировочная на сегодня).
Язык доступа - отдельно: SQL-92, PL\SQL, T-SQL, Java, .Net ...etc

[Ludwig]

Сообщение от tadpole

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

Вполне возможно описать и правила и действия.

Чтоб лучше понять всё это надо плясать от языка, а не от самих фич РСУБД, потому что всё что может РСУБД - есть в SQL, верно? Вот берем язык, разбираем его по косточкам и смотрим что есть такого прямо невозможного, что не перенесется в мой язык.

Ludwig добавил 02.09.2008 в 16:34

Сообщение от YellowMan

Это совершенно разные вещи - язык программирования и модель хранения данных.
Они как-бы совершенно не пересекаются.

Нет, это не разные вещи, это одно и то же.