Delphi for zOS

[katit]

А что делать с информацией которая по определению в виде многосвязных графов?

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

Можно хранить в таблицах.
Можно использовать специальные базы данных, такие есть (Ориент например).
У информикс когда-то была технология DataBlade.
Она позволяла создавать новые типы данных и встраивать операции с ними праймо в БД.

Ну и можно хранить как BLOB а обработку написать на C/C++/C#/Java/...
Для этого есть библиотеки и фрамеворки.

В том же SQL Server все есть. И в других думаю тоже.

[iDesperado]

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

что за бяда ? чем появление таблички с подпозициями будет отличаться от появления подпозиций в каком-нибудь json ?

[tessob]

2 iDesperado: Признаю, что криво выразил свою мысль. Представим, потом еще выяснится, что есть еще разные виды заказов, у которых отличается структура позиций и подпозиций. Например, длинны и/или количества полей разные и т.п. В общем изменения происходят постоянно и уйти от этого не возможно. В итоге база начнет описывать сразу несколько концепций хранения данных. Вот, ИМХО, в таких случаях noSQL имеет преимущества т.к. мне не нужно поддерживать в SQL легаси поля. А так же мой json описывает реальные данные именно в том виде, в котором их необходимо хранить. При этом мне не нужно думать в каких случаях и для каких объектов какие таблички и поля нужно читать, а какие нет.

З.Ы. Может конечно это только мне так со SQL не везло. Хотя признаю, что иногда SQL лучше. Вообще-то я сторонник комбинирования обеих технологий, если это необходимо.

[iDesperado]

2 iDesperado: Признаю, что криво выразил свою мысль. Представим, потом еще выяснится, что есть еще разные виды заказов, у которых отличается структура позиций и подпозиций. Например, длинны и/или количества полей разные и т.п. В общем изменения происходят постоянно и уйти от этого не возможно. В итоге база начнет описывать сразу несколько концепций хранения данных. Вот, ИМХО, в таких случаях noSQL имеет преимущества т.к. мне не нужно поддерживать в SQL легаси поля. А так же мой json описывает реальные данные именно в том виде, в котором их необходимо хранить. При этом мне не нужно думать в каких случаях и для каких объектов какие таблички и поля нужно читать, а какие нет.

тут как раз у SQL преимущество - ты просто увеличиваешь размер поля, добавляешь колонки и в отличие от бигдата ничего нигде не падает. в оракле вообще иделаьно, с его %ROWTYPE или %TYPE. и в этом плане после оракла на бигдата плакать хочется. у нас последние три релиза падали, потому что в paquet не та версия avro, какую код ожидал. с точки зрения оракла просто дикость.

[Flash-04]

Есть довольно большая область работы с данными где SQL не только не нужен, а даже мешает: log management. Я давно с этим работаю и воочию наблюдал как вендоры начали с SQL БД и потом были вынуждены уйти к noSQL именно из-за проблем с производительностью.

[iDesperado]

Есть довольно большая область работы с данными где SQL не только не нужен, а даже мешает: log management. Я давно с этим работаю и воочию наблюдал как вендоры начали с SQL БД и потом были вынуждены уйти к noSQL именно из-за проблем с производительностью.

сейчас spark всех в зад на SQL вернет

[tessob]

после оракла на бигдата плакать хочется

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

Kill them all and let Krishna sort them out!

[Flash-04]