Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп.

Здесь подробно рассматривались все аспекты
https://www.sql.ru/forum/973198/db-specific-orm
Что значит "полностью соединяет"?
Замена термина "маппинг" термином "трансляция" не может избавить от архитектуры "модль верхнего уровня+маппинг+РМД"
U-gene
...Поэтому я сразу даю видео, где показано как эта СУБД работает и объяснены основные принципы как можно объединять ОО и РМ, так, что бы они друг другу не мешали, и даже помогали.

В известной статье, на которую указал servit, проблемы маппинга рассматриваются вскользь и весьма туманно:

"Исходя из особенностей реляционной машины, процесс трансляции описывается схемой "имена-->(трансляция)-->имена", то есть, имена структур памяти реляционной машины формируются из имен, вводимых при описании объектных структур. При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины."

Весьма не формально - "тесно связаны"))
И в презентации нет разъяснений. Какая МД используется на верхнем уровне? Если это МД, то маппинг должен поддерживаться по всем трем аспектам: структура, ОЦ, манипулирование. Как это осуществляется?
Можно только предположить, что в качестве МД верхнего уровня используется либо М4, либо М5
13577413
U-gene
Тема запутанная, у людей в голове каша, двумя словами от этой каши не избавишь, а на словесные баталии мы потратим больше времени, чем 36 минут (длительность видео). Я даже не настаиваю: хотите - смотрите, не хотите - не смотрите.

Потратил 108 минут. Для начала))...
29 май 13, 20:20    [14366716]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
U-gene
Basil A. Sidorov
пропущено...
Есть одна проблема - нет реализации.
А в видео что? Я же не на пальцах объясняю.
Именно, что на пальцах.
Очередные подтяжки для тех, кто не хочет или не может освоить декомпозицию.
Я не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"
29 май 13, 21:08    [14366878]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина, (о! наши подошли :) )
я давно Вам говорил - я не хочу думать о моделях верхнего уровня. Я не думаю о сущностях и связях. Есть СУБД (система), для ее управления используется язык, в нём есть языковые конструкции, позволяющие описывать те или иные структуры данных и даже классы (т.е. структуры данных и применимые к ним методы)

Я Вашу M-классификацию давно видел. Сейчас еще раз посмотрел. С учетом того, что я предлагаю эволюцию РСУБД (этот момент в видео дан "на пальцах") и таблицы никуда не денутся, а мои классы могут использоваться как домены этих таблиц, то в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте. Впрочем я на этом настаивать не буду и спорить не хочу.

И термин маппинг я именно по этой причине вопинимаь не хочу. Речь идет о трансляции , т.е. о механическом переписывании входных команд в выходные на основании данных о структуре, сохраненных в таблице имен.
29 май 13, 21:42    [14367039]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene
Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. .

Ну , к примеру, ОРСУБД тоже "соединяет" ОО и РМ. Ну и существуют типа ОРСУБД. Т.е. самом по себе "соединяет ОО и РМ" вроде как ничего не меняет в топике: обе структурированные МД (типа "жесткие структуры").
А ТС вроде хотел типа "гибкой структурой".
Скорее всего, в литературе по БД речь идет о полуструктурированных, слабоструктурированных МД. К ним ни ОО и РМ и, скорее всего, их "соединения" не относятся.
29 май 13, 21:48    [14367067]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
vadiminfo
U-gene
Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. .

Ну , к примеру, ОРСУБД тоже "соединяет" ОО и РМ. Ну и существуют типа ОРСУБД. Т.е. самом по себе "соединяет ОО и РМ" вроде как ничего не меняет в топике: обе структурированные МД (типа "жесткие структуры").
А ТС вроде хотел типа "гибкой структурой".
Скорее всего, в литературе по БД речь идет о полуструктурированных, слабоструктурированных МД. К ним ни ОО и РМ и, скорее всего, их "соединения" не относятся.

ТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой". Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.
Что касается OРСУБД - там объекты только в названии. UTD до полноценных классов никак не тянут. а попытка натянуть их на таблицы нарушает РМ даже в формальной части.
29 май 13, 22:08    [14367121]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Максим Н
Member

Откуда: Екатеринодар
Сообщений: 1439
U-gene
ТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой". Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.

Так и есть.
29 май 13, 22:24    [14367177]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene
ТС в первом посте дал более четкое описание, что имеется в виду под "гибкой структурой".
Судя по этому описанию, имелось в виду "как согнул, так и будет, самое главное, что бы гнулась в любую сторону", хотя я могу и ошибаться.

Не знаю что тут четкого. Но, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. И в ОО и в РМ это означает изменение МД. И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.

То что описал ТС хоть и не четко, но типа в сторону полуструктурированных. Например, XML СУБД. Т.е. они тоже могут не подойти, но они, скорее всего, ближе, чем структурированные.

U-gene
Что касается OРСУБД - там объекты только в названии. UTD до полноценных классов никак не тянут. а попытка натянуть их на таблицы нарушает РМ даже в формальной части.

Это детали.
"Обектно" не означает существование полноценности классов. А нарушение базовой РМ при ее расширениях неизбежны. Иначе в чем расширение, если все осталось как было.
29 май 13, 22:44    [14367232]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
vadiminfo
Это детали.
"Обектно" не означает существование полноценности классов. А нарушение базовой РМ при ее расширениях неизбежны. Иначе в чем расширение, если все осталось как было.

1) Это не детали.
2) Насчет расширений.
Идея как раз в том, что вообще не надо ничего расширять. У меня следующая аналогия. Есть квадрат и есть круг. Требуется найти что то, что было бы и круглым и квадратным. Все пытаются как то "расширить" одну фигуру до другой и изобразить то закругленный квадрат, то оквадраченный круг (...не знаю, что это такое, сами попробуйте представить). Моя система в этой аналогии - цилиндр. Одна проекция - правильный круг, другая (ортогональная) - правильный квадрат, а для того, что бы соотнести проекции используются имена, общие для обеих проекций.
30 май 13, 01:53    [14367653]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
vadiminfo
Но, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. .... И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.

Причем здесь пользователь? А я? Я не пользователь, но с С на С++ и дальше на С# (или Java) сам по своей воле переползал (вместе со всем миром). Потому что мне, как разработчику, тоже удобнее думать в ОО терминах.

Думайте как хотите. Дать пользователю или не себе оставить - вообще не моя проблема. Было бы что.
30 май 13, 02:15    [14367667]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Максим Н
Member

Откуда: Екатеринодар
Сообщений: 1439
Ну эта, я тут пока жу как я это себе представляю, по поводу графов (см. картинку).
Атрибуты пока не зарисовал и думаю и так понятно, чтобы не нагромождать картинку.

К сообщению приложен файл. Размер - 63Kb
30 май 13, 06:46    [14367743]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Максим Н
Member

Откуда: Екатеринодар
Сообщений: 1439
Тут на всякий случай Cypher-код создания базы (той что на картинке):

+

// START n = node(*)
// MATCH n-[r?]-()
// DELETE n, r;


//Create root entity
CREATE (a {name : 'Base Abstract Entity'})
RETURN a;

//Create entity
CREATE (a {name : 'Vehicle'})
RETURN a;

CREATE (a {name : 'Car'})
RETURN a;

CREATE (a {name : 'Plane'})
RETURN a;



START left=node(*), right=node(*)
WHERE (left.name="Base Abstract Entity" and right.name="Vehicle")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;


//
START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Car")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Plane")
CREATE UNIQUE left-[r:ENT_TYPE_INH]->right
RETURN left, right;







//Create vehicle attributes types
CREATE (a {name : 'Speed'})
RETURN a;

CREATE (a {name : 'Power'})
RETURN a;

CREATE (a {name : 'Size'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Speed")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Size")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Vehicle" and right.name="Power")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;




//Create car attributes types
CREATE (a {name : 'WheelsCount'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="WheelsCount")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;



//Create plain attributes types
CREATE (a {name : 'WingsCount'})
RETURN a;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="WingsCount")
CREATE UNIQUE left-[r:ATTR_TYPE]->right
RETURN left, right;





//Create cars objects
CREATE (a {name : 'Ferrary F50'})
RETURN a;

CREATE (a {name : 'BMV'})
RETURN a;

CREATE (a {name : 'VAZ'})
RETURN a;


START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="Ferrary F50")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="BMV")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Car" and right.name="VAZ")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;







//Create planes objects
CREATE (a {name : 'Boeng'})
RETURN a;

CREATE (a {name : 'Aerobus'})
RETURN a;

CREATE (a {name : 'SuperJet'})
RETURN a;


START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="Boeng")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="Aerobus")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;

START left=node(*), right=node(*)
WHERE (left.name="Plane" and right.name="SuperJet")
CREATE UNIQUE left-[r:OBJ]->right
RETURN left, right;
30 май 13, 06:49    [14367747]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
...я давно Вам говорил - я не хочу думать о [b]моделях верхнего уровня. Я не думаю о сущностях и связях. Есть СУБД (система), для ее управления используется язык, в нём есть языковые конструкции, позволяющие описывать те или иные структуры данных и даже классы (т.е. структуры данных и применимые к ним методы)

Еще раз:
"Исходя из особенностей реляционной машины, процесс трансляции описывается схемой "имена-->(трансляция)-->имена", то есть, имена структур памяти реляционной машины формируются из имен, вводимых при описании объектных структур. При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины."
На стороне "реляционной машины" есть логическая МД. Вы утверждаете, что МД верхнего уровня может быть любая. Тогда нужно ясно показать, как любая МД верхнего уровня может использоваться в Вашей, не ориентированной ни на какую конкретную модель СУБД???
U-gene
Я Вашу M-классификацию давно видел. Сейчас еще раз посмотрел. С учетом того, что я предлагаю эволюцию РСУБД (этот момент в видео дан "на пальцах") и таблицы никуда не денутся, а мои классы могут использоваться как домены этих таблиц, то в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте. Впрочем я на этом настаивать не буду и спорить не хочу.

Не нужно настаивать и спорить. Нужно просто взять, например, М2 и показать на примере.
Но, пока, очень важный момент: Вы, все-таки, строго по Дейту делаете - подтвердите еще раз, что класс неизвестной, пока, МД верхнего уровня - это ДОМЕН РМД. То есть, Фамилия Человека, например, - это у Вас класс. Так? А Человек тогда что?
U-gene
И термин маппинг я именно по этой причине воспринимать не хочу. Речь идет о трансляции , т.е. о механическом переписывании входных команд в выходные на основании данных о структуре, сохраненных в таблице имен.

И еще раз, для верности:
"... При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины."
Покажите на примере, пожалуйста.
30 май 13, 07:14    [14367762]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Максим Н,

Субд тут ни при чем, на базе любой можно сделать такое приложение. Дело в том как делать, а не в субд.

Как делать — читай про EAV.

Но кстати есть субд и специально на это ориентированные, RDF storage например.
Можешь также прочитать про rdf и sparql.
30 май 13, 11:33    [14368889]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vvm
Member

Откуда: Не помню
Сообщений: 9968
U-gene
vadiminfo
пропущено...

Ну не все же любители подобного рода видио, когда рядом есть "Уральские пельмени". Поэтому как бы такие дополнительные пояснения, возможно, следует отнести к чрезмерно громоздкими, чтобы с ними можно было ознакомиться.
Если я просто заявлю, что существует СУБД (в виде прототипа), которая полностью соединяет ОО и РМ, то многие участники дискуссии начнут крутить пальцем у виска, начнется холивар и тп. Ситуация для меня обычная, привычная и понятная. Поэтому я сразу даю видео, где показано как эта СУБД работает и объяснены основные принципы как можно объединять ОО и РМ, так, что бы они друг другу не мешали, и даже помогали. Тема запутанная, у людей в голове каша, двумя словами от этой каши не избавишь, а на словесные баталии мы потратим больше времени, чем 36 минут (длительность видео). Я даже не настаиваю: хотите - смотрите, не хотите - не смотрите.

Ну вот я просмотрел видео.

Единственный вопрос.

Какая связь между вашей RxO и текущей темой: "Хранение данных с гибкой структурой и запросы к ним"?
Никакой.
30 май 13, 12:28    [14369331]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene
Идея как раз в том, что вообще не надо ничего расширять. .

Если добавляетсся ОО, то с одной расширение как бы есть, так как ничего из ОО (классов, методов...) в РМ нет. С другой, если расширеня нет, то это просто то что и было: ниче нового.

U-gene
Причем здесь пользователь?
.

Для него пользователя здесь "гибкая структура" у ТС, наколько я понял. А иначе "негибкой структуры" бы как и везде хватило: проектировщик то не буит к нему кажный день ходить структуры гнуть.
30 май 13, 12:36    [14369417]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
ViPRos
Member

Откуда:
Сообщений: 9965
vadiminfo
Но, скорее всего, речь идет об избитой идее модификации структуры конечным юзером. И в ОО и в РМ это означает изменение МД. И это обычно требует известной квалификации и отвественности проектировщика. А если юзер буит делать, то, есть риски, что старые запросы могут мягко говоря показывать совсем не то, что должны бы. А новые писать геморно будет и опытному базисту.


1.не МД, метаинформации для создания модели предметной области
2.изменение модели пользователем - архиважная фигня
3.рисков никаких не должно быть
4.все должно быть структурировано до безобразия

для того что бы 2-4 работало, ОО и РМД маловато будет (С РМД то фиг с ним, можно выкрутится, а ОО маловато)
30 май 13, 12:46    [14369516]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
U-gene,

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

- Насколько реально ликвидированы проблемы состыковки объектных данных и данных в РМ ?

Имеются в виду не политические вопросы, а реальные технические проблемы. Непонятно, как будет функционировать продукт. Предполагаю, что это какой-то "sql-сервер" как прослойка к настоящему серверу СУБД. В этом случае в рамках клиентского кода (относительно СУБД) я должен на основе типовых технологий продолжать работать как и раньше, только теперь "sql-" или "RxO-"запросы я отправляю не серверу СУБД, а какому-то серверу RxO. Т.е. можно создать какой-то программный каркас (например, что-то по мотивам ORM), понимая, что на той стороне уже живёт какая-то объектная СУБД, с похожей на ООП моделью данных, и вместо sql-кода теперь нужно оперировать новым языком, отправлять запросы и считывать те же табличные результаты, их сохраняя или обрабатывая согласно концепции ООП-каркаса внутри клиентского кода.

Или же это какой-то Акцесс/фокспро или как проект Animotron, здесь выше давали ссылки на него. Т.е. это некая пусть виртуальная машина, которая интегрировано предоставляет весь цикл разработки и сама исполняет закладываемый широкий функционал. Ну, например, имеется ли взаимодействующий с данными слой презентации, где в скрипте можно задать "create form ..." и где-то выдать "select <что-то> into <такая-то форма> ", в результате на экран можно вывести форму или сервер сформирует HTML/javascript/json- и пр. ответ.

Или есть ли какая-то технология выше над моделью хранимых данных. К примеру, есть ли дополнительные операторы в языке для взаимосвязанного описания классов, которыми уже оперируют на клиентской стороне, затем при "исполнении" кроме sql-запросов непосредственно для СУБД будут ещё генерироваться java/C# и пр. классы. Т.е. что-то вроде "M моделирования" от майкрософт.

Одним словом, непонятно как использовать продукт. Или это только прототип возможного языка на "сервере" ?


- Насколько реально возможна трансформация жизненно необходимого исходного SQL ?

Есть ли возможность оперировать, скажем, рекурсивными запросами. Или возможны ли какие-то инварианты. Ну, например, если я применю одно объектное выражение, которое заставит систему генерировать sql с подзапросами, а если по-другому - получим соединение таблиц (это, конечно, всё условно, я понимаю, что об оптимизации заботятся изначально). Или есть ли какая-то лазейка для прямой спасительной sql-инъекции, если система чего-то не может.
Всё таки, подобные абстракции над какой-то Key-Value базой, когда за рамками контролирующего прикладного ядра лучше и не лазить напрямую в БД - это одно. А если система уже поверх мощного SQL заставит вести не малую часть разработки за своим бортом - это другое.

- На сколько развит сам язык моделирования и запросов ?

Как я понимаю, делается попытка быть поближе к SQL, но с ООП-мотивами. Язык SQL хоть и декларативный, но очень прямолинеен. В нём элементарно задалбывает вручную оперировать, например, большими списками столбцов и связанных с ними данных. Или слабый потенциал для инвариантности вынуждает формировать в коде несколько вариантов SQL-оператора, который за собой тянет и варианты окружающего кода. Есть ли какие-то технологии, облегчающие жизнь. Например, как-то так:
-- ниже "a", "b", "c" обычные переменные:
a := 23;
b := 345.678;
c := "привет ...";

-- ниже кортеж или объект с именованными полями (a, b, c), где оператор "..."
-- указывает на действия по умолчанию (т.е. b = b, c = c)
rec := (a = a, ...);

-- обновляем класс
UPDATE <класс>[<какое-то where>] SET rec; 



- Насколько развита ООП-технология как такова ?

Например, есть ли понятие явных конструкторов, с их наследованием. Возможны ли какие-то механизмы типа дженериков или какого-то параметрического полиморфизма. Есть ли механизм "виртуальных вызовов". Например, пусть я сформирую выборку из объектов разных классов (подклассов) (пока даже не знаю как, возможно, через какой-то "union"), и укажу выполнить метод как-то так: "FOR <выборка> EXEC <метод>", и соответственно я должен ожидать то, что для каждого объекта будет "выполнен" корректный метод нужного класса. И пр.


Ну и ещё один момент. Почему именно ОПП, в принципе, очевидно. Если отбросить вопросы целевого позиционирования продукта, скажем, для своих потребностей, или в дополнение к ООП. Короче говоря, не анализировался ли возможный подход организации каких-то абстрактных типов и независимых операций (по мотивам классов или протоколов типов, к примеру) ?

Всё таки, ООП само по себе имеет немало допущений и неоднозначности, и проблем, для проектирования, моделирования, да и в реализации. От того постоянны разговоры как наследовать прямоугольники с квадратами, "дверь в комнату" сама открывается или её открывает "входящий". Множественное наследование даёт технические проблемы, и, в целом, наследование с понятием субтипа иногда (или не редко) вынуждает приводить реальный тип объектов к верхнему базовому типу, с которым ничего толком и не сделаешь, без вынужденного небезопасного последующего приведения типа. Без относительно строгой типизации вполне можно слонов с мухами складывать и т.д. и т.п. Хотя, собственно, притащить проблемы ОПП в проект можно настолько, насколько эмулируется это ООП.

Спасибо.

P.S. Если подобные вопросы постоянно задают, м.б. есть смысл дать какую-то ссылку, где всё уже по полочкам разложено.
30 май 13, 14:48    [14370516]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11463
U-gene
Я не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"
Своей презентацией вы продемонстировали:
а) универсальность реляционных СУБД
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным.
Что касается декомпозици ...
В основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.
Отсюда и автогенерация схем и автоматическое построение запросов и аннотации для указания связей и т.п.
На самом же деле приложение "видит" данные через призму DML, а отображение этих самых DM на объекты - вторично, т.к. сильно зависит от семантики.
Нужно просто принять как факт, что реляционная алгебра - проста. И научиться решать реляционные задачи точно так же, как в школе решались квадратные уравнения.
30 май 13, 18:42    [14372187]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
Basil A. Sidorov
U-gene
Я не понял, что тогда подразумевается под "отсутствием реализации", как из этого следуют "подтяжки для тех, кто не хочет или не может освоить декомпозицию", и что имеется в виду под "освоить декомпозицию"
Своей презентацией вы продемонстировали:
а) универсальность реляционных СУБД
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным.
Что касается декомпозици ...

Имхо, вполне оправданы попытки привести технологии реализации в гармоничный вид. Я имею в виду то, что сама по себе гармония важна. Вот во времена клиперов с фокспро была отличная гармония, реляционная модель и внутри БД, и она же в "клиенте". Как только начали появляться классы с объектами, на ту же фокспро стало противно смотреть. Такова уже историческая особенность мэйнстрима, что ему навязали ООП как серебряную пулю, преподнесли не только как продвинутый препроцессор для ассемблера, но и как средство уже системного моделирования, но для чего ООП, фактически, не пригодно.

Сегодня как раз был разговор на подобную тему в другом форуме, приведу цитату оттуда:
Илья Ермаков
Кстати, возможно, серьёзное заблуждение в том, что "устаканить" и качественно построить уровень системного проектирования, моделирования и т.п. можно полностью изолированно от уровня реализации (наплевав на то, какие технологии лежат ниже, на уровне программной реализации).
Наконец-то все в ИТ усвоили идею абстрагирования, изоляции нижележащих особенностей... Но уверовали в другую крайность - "всё равно, на чём реализовывать, главное спроектировать и правильно поставить процесс".

Однако в инженерии не всё так просто - и уровень реализации, "материал", не может не оказывать влияния на общую архитектуру системы. Мало ли примеров в технике, когда именно новые материалы, или новые технологии изготовления делали возможными новые конструктивные решения, которые раньше были невозможны?
Наивно считать, что можно было бы полететь в космос, не имея всего пакета качественных технологий на всех уровнях: механика, приборостроение соответствующей точности, культура производства каждой детальки, материалы с нужными свойствами...
Считается очень плохим, когда конструкторы оторваны от технологов - фигня обычно получается. (Даже на самом простейшем производстве это проявляется в том, что, допустим, размеры на чертеже будут проставлены таким из нескольких возможных способов, что при изготовлении придётся делать несколько установок детали в станок, теряя точность...)
Так же наивно считать, что бардак на уровне технологий и методов программирования можно полностью подавить вышележащим уровнем - проектированием и менеджментом. Частично, конечно, подавляют... Но то, что на нижнем уровне бывает сооружено из г-на, даёт о себе знать. Кроме того, при использовании адекватных инструментов на нижнем уровне проблем на верхний просачивается меньше - и то, что решалось выше, решается ниже и само собой... Чем раньше предотвращена ошибка, тем лучше.

Подход, когда аналитики и архитекторы должны непосредственным образом участвовать и в работе команды программистов (сами огребать все проблемы в реализации того, что они наанализировали и напроектировали), пропагандирует, кстати, Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).
31 май 13, 01:44    [14373214]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
PSV100
Имхо, вполне оправданы попытки привести технологии реализации в гармоничный вид. Я имею в виду то, что сама по себе гармония важна. Вот во времена клиперов с фокспро была отличная гармония, реляционная модель и внутри БД, и она же в "клиенте".


Это не была гармония. Это было что-то с чем-то.
Но за не имением лучшего, приходилось использовать.
Когда появились достаточно производительные SQL-сервера по разумной цене, так все СУРБД на основе xBase (д и других процедурных ЯП) тут же ушли "в тень".

PSV100
Как только начали появляться классы с объектами, на ту же фокспро стало противно смотреть.


Если что, то в FoxPro давно есть классы и объекты.
Даже в Clipper 5.1 уже были классы объекты.
Не в них дело, а в доступных SQL-серверах.

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


Ну не думаю, что такое резкое высказывание "... средство уже системного моделирования, но для чего ООП, фактически, не пригодно..." верно.
Системное моделирование как раз просто и прозрачно реализуется в ООП.
Просто попытка в ООП ЯП "втиснуть" SQL в виде ORM, приводит к проблемам, когда возможностей SQL не хватает.
Фактически нужно написать свой "SQL", только не SQL.
Для простых вещей это можно, для сложных нет.

Поэтому создание "гибкой структуры" - миф.
Гибкая структура уже есть - SQL-сервер ;-)
31 май 13, 07:26    [14373355]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
mad_nazgul
Когда появились достаточно производительные SQL-сервера по разумной цене, так все СУРБД на основе xBase (д и других процедурных ЯП) тут же ушли "в тень".
...
Если что, то в FoxPro давно есть классы и объекты.
Даже в Clipper 5.1 уже были классы объекты.
Не в них дело, а в доступных SQL-серверах.
...

У xBase, конечно, хватало тараканов, но как раз без их классов и было проще делать свои абстракции. А при возможности xBase приспособили бы для серверов, но их ключевой индексно-последовательный метод работы с данными в принципе не позволяет реализовать адекватную работу интенсивных параллельных транзакций (или пользователей). Это как раз пример того, что "материал" не может обеспечить требуемую технологию производства.

mad_nazgul
Ну не думаю, что такое резкое высказывание "... средство уже системного моделирования, но для чего ООП, фактически, не пригодно..." верно.
Системное моделирование как раз просто и прозрачно реализуется в ООП.

У меня свой опыт и несколько иное мнение. Недавно в соседней теме форума возникал подобный офтоп, поделюсь ссылкой.

mad_nazgul
Просто попытка в ООП ЯП "втиснуть" SQL в виде ORM, приводит к проблемам, когда возможностей SQL не хватает.
Фактически нужно написать свой "SQL", только не SQL.
Для простых вещей это можно, для сложных нет.

Я несколько лет назад встретил проект на Кложуре, для меня это образцово показательные выступления. Здесь выше давали ссылку на соседнюю тему DB specific ORM, что заставило опять поискать этот проект в инете, не нашёл (и названия не помню). Вот там не было никакого ООП с ORM. На пальцах, конечно, фигово рассказывать. В двух словах, были свои абстракции верхнего уровня, выражающие предметную область, приводились примеры каких-то документов, понятий операций с ними и пр. На уровне ниже строилась модель данных, причём именно в привязке к реляционной модели, где чётко указывалось, типа эта таблица такая-то, для хранения "шапок" документов, эта таблица с их "строками" и т.п. Естественно всё взаимосвязано по уровням, при этом задавались не только таблицы с индексами и отношениями, но и конкретный код хранимок и триггеров и пр. SQL-код задавался тоже на своём лисп-DSL, напоминающий насколько это возможно исходный SQL. Была конкретная привязка к постгресу, были свои ограничения по языку. В итоге "компилировался" конечный SQL. Закладывалась возможность и обратной трансформации, из SQL -> лисп. И, самое главное, делались попытки задания инвариантности моделей, через конструкции по мотивам pattern matching. Далее согласно архитектуре уже конкретного приложения можно привлекать слои создания коллекций в памяти, делать свою обработку, подключать слой презентации и т.д. (в Кложуре те же вэб-фрэймворки строятся на схожих принципах).

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

Имеются свои подобные наработки, но не на таком глубоком уровне, и не на лиспе.

mad_nazgul
Поэтому создание "гибкой структуры" - миф.
Гибкая структура уже есть - SQL-сервер ;-)

Ну почему же миф, если отбросить маркетинговую шумиху вокруг NoSQL, то, всё таки, иногда есть вполне оправданные причины быть за рамками SQL-сервера, и нагрузку они могут не вытянуть, и гибко не распределять и т.д. Но и на SQL-серверах можно тоже пытаться выжить, к примеру, скайп же делится своими Skytools.
31 май 13, 15:12    [14376316]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
PSV100
У xBase, конечно, хватало тараканов, но как раз без их классов и было проще делать свои абстракции. А при возможности xBase приспособили бы для серверов, но их ключевой индексно-последовательный метод работы с данными в принципе не позволяет реализовать адекватную работу интенсивных параллельных транзакций (или пользователей). Это как раз пример того, что "материал" не может обеспечить требуемую технологию производства.


Какие абстракции в xBase?!
Все крутилось вокруг таблицы.
Желательно одной.
Связь м/у двумя уже такой геморрой.
Есть таблица, с ней можно что-то сделать.
Если есть связь...
Здравствуйте циклы.
Плюс сам язык, который способствовал "лапшекоду".
В этом плане FoxPro был "глотком свежего воздуха", т.к. в нем появились элементы SQL.
Что позволило хоть как-то работать с отношениями м/у таблицами.

PSV100
У меня свой опыт и несколько иное мнение. Недавно в соседней теме форума возникал подобный офтоп, поделюсь ссылкой.


У меня то же свой опыт и то же свое мнение. :-)
В ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

PSV100
Я несколько лет назад встретил проект на Кложуре, для меня это образцово показательные выступления. Здесь выше давали ссылку на соседнюю тему DB specific ORM, что заставило опять поискать этот проект в инете, не нашёл (и названия не помню). Вот там не было никакого ООП с ORM. На пальцах, конечно, фигово рассказывать. В двух словах, были свои абстракции верхнего уровня, выражающие предметную область, приводились примеры каких-то документов, понятий операций с ними и пр. На уровне ниже строилась модель данных, причём именно в привязке к реляционной модели, где чётко указывалось, типа эта таблица такая-то, для хранения "шапок" документов, эта таблица с их "строками" и т.п. Естественно всё взаимосвязано по уровням, при этом задавались не только таблицы с индексами и отношениями, но и конкретный код хранимок и триггеров и пр. SQL-код задавался тоже на своём лисп-DSL, напоминающий насколько это возможно исходный SQL. Была конкретная привязка к постгресу, были свои ограничения по языку. В итоге "компилировался" конечный SQL. Закладывалась возможность и обратной трансформации, из SQL -> лисп. И, самое главное, делались попытки задания инвариантности моделей, через конструкции по мотивам pattern matching. Далее согласно архитектуре уже конкретного приложения можно привлекать слои создания коллекций в памяти, делать свою обработку, подключать слой презентации и т.д. (в Кложуре те же вэб-фрэймворки строятся на схожих принципах).


ИИ еще никто не разработал.
Были попытки в т.ч. и на lisp'е. ;-)
Процесс моделирования - это процесс творческий.
Можно создать много шаблонов, но всегда найдется задача, в текущем проекте, которая не подходит под шаблон. :-)



PSV100
Ну почему же миф, если отбросить маркетинговую шумиху вокруг NoSQL, то, всё таки, иногда есть вполне оправданные причины быть за рамками SQL-сервера, и нагрузку они могут не вытянуть, и гибко не распределять и т.д. Но и на SQL-серверах можно тоже пытаться выжить, к примеру, скайп же делится своими Skytools.


Мы же говорим за реляционную модель... ;-)
По моему проблема NoSQL в том, что нет за ними "мощных" математических теорий.
Все на эвристике.
Соответственно, по идее они могут все, а когда доодит дело до конкретики начинают вылезать "особенности".
SQL - в этом плане более "простой". Всегда точно можно сказать что он может и как может.
И там где мы точно уверены, что SQL - не может. Там его и не надо применять.
С NoSQL такого сказать нельзя, они "по определению" могут все, а вот на практике... ;-)
31 май 13, 16:24    [14376795]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Татьяна Милина
Member

Откуда:
Сообщений: 1
Это не СУБД, а фраймворк!
31 май 13, 16:34    [14376866]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
mad_nazgul
В ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.

mad_nazgul
По моему проблема NoSQL в том, что нет за ними "мощных" математических теорий.
Все на эвристике.

Отчасти есть, те же исчисления на графах не с потолка. Другое дело, что ещё только идёт процесс становления технологий, устаканивание моделей данных с их физической организацией и т.д. Тех же языков высокого уровня над теми же графами куча разных, причём это не отличия "в диалектах". Вылазят и древние решения, но яко бы уже на новом уровне. Плюс решения в рамках NoSQL, в основном, пока для специализированных задач. В общем, нормальный процесс эволюции, ведь по сравнению с прошлой эпохой только сейчас столкнулись с такими масштабами данных, с такой параллельной нагрузкой, с такими требованиями быстрых реакций и т.д.
31 май 13, 18:33    [14377405]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11463
PSV100
Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.
Давит причём не на мозги, совсем другое - реальная жизнь со всеми её исключениями из правил и нестыковками.
Презентация, кстати весьма показательна - такую реализацию понятия "(расчётный) счёт" надо выкидывать на помойку. Ещё до прототипирования.
1 июн 13, 09:51    [14378616]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить