Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Ты эта, миччел :) не гони с версионностью то.... дай в прЫнцыпах разобраться...:)

автор
В FastObjects объекты и описания классов хранятся раздельно (в разных базах/файлах). Поэтому, при появлении, например, нового атрибута в описании класса нам нужно только внести новое описание в базу с описаниями классов (словарь) - база объектов остается неизменной. Это делается совершенно элементарно (можно и через консоль, но это даже менее удобно, чем с помощью специальных средств импорта описаний классов из байт-кода Java или C++-исходника).


То есть УЖЕ есть описание объектов в программе, и мы должны это описание еще и в СУБД как то засунуть? Я тогда не пойму, как можно говорить о
автор
трансформации структуры хранимых объектов в самом приложении
ведь, само приложение же при этом перекомпилять надо? А если не перекомпилять (или наоборот - перекомпилить, но не засунуть эти изменение в СУБД), то оно работать не будет? То есть получаеться что эта штука не является независимой от приложения? А за что тогда боролись то....?

...или это я чего то не понимаю?
3 фев 05, 17:51    [1298469]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
миччел - это, конечно, мил.чел. .... На всякий случай, заранее извините за стёб....:)
3 фев 05, 17:55    [1298488]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron

Насчет маяков - есть разные способы хранения такого типа данных. Например, во всех нормальных СУБД (например, Oracle) есть поддержка XML, неструктурированные данные могут быть в XML, а описываться схемой. А дальше - дело техники.


Если сравнивать методику и возможности обработки XML-документов в Oracle и FastObjects, то, полагаю, преимущество будет на стороне последнего.
Если кто-то действительно интересуется темой хранения и обработки XML-данных с помощью FastObjects то рекомендую почитать здесь.
3 фев 05, 17:57    [1298497]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...

То есть УЖЕ есть описание объектов в программе, и мы должны это описание еще и в СУБД как то засунуть? Я тогда не пойму, как можно говорить о
автор
трансформации структуры хранимых объектов в самом приложении
ведь, само приложение же при этом перекомпилять надо? А если не перекомпилять (или наоборот - перекомпилить, но не засунуть эти изменение в СУБД), то оно работать не будет? То есть получаеться что эта штука не является независимой от приложения? А за что тогда боролись то....?

...или это я чего то не понимаю?


Для трансформации структуры "на лету", разумеется, нужно использовать специальные API. Для VDS вам такую возможность продемонстрировали. Что же касается FO, то достаточно заметить, что сам "словарь" с описаниями классов является такой же базой данных, как и база с объектами. Т.е. в эту базу можно обращаться из приложения и изменять, хранящиеся там описания классов. Но все-таки FO менее приспособлен для такого обращения, там это скорее присутствует в виде дополнительного бонуса, а вот в VDS такая функция на практике востребована чаще.
3 фев 05, 18:23    [1298591]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2Alexey Rovdo
Тогда мне непонятно, в чем заявленное преимущество ООСУБД в плане модификации сущностей перед РСУБД. РСУБД как минимум не сложнее, а чем-то даже и проще.

Кстати, как будет проводиться тогда сравнение типов объектов? Ведь фактически (рассмотри мой пример) добавление атрибута означает создание другого класса. Пусть typeof - функция получения типа объекта
/*Старый объект, был сохранен до изменения структуры*/
A a_old = new A();

/*Новый объект, создается после изменения структуры*/
A a_new = new A();

if typeof(a_new) == typeof(a_old) {
...
};
Как такое будет работать?

Второй вопрос.
В классе один из атрибутов был переименован или изменен его тип. Как такие изменения вносятся в БД? Как происходит преобразование данных в этом случае? Как обстоят дела с индексами?
3 фев 05, 18:23    [1298592]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest

public class A {
long propertyA;
long propertyB;
long propertyC;

void funcA () {
A a_obj = new A();
};



AAron хотел примера работы - пожалуйста :
...
ClassHandle cls=session.locateClass("A");
AttrByteArray prop = session.newAttrByteArray("propertyD");
AttrBuilder builder=session.newAttrBuilder(prop);
cls.appendAttr(builder);

......
FundVQLQuery vql=new FundVQLQuery(session,"select from A");
HandleEnumeration he = vql.execute();

Attr attr=cls.getAttr("propertyD");
// инициализирую аттрибут
while (he.hasMoreElements()) {
Handle handle = (Handle) he.nextElement();
handle.putObject(attr,null);
}
.....
по поводу наследников - все наследники, A есть A то есть код верен и для них
3 фев 05, 18:28    [1298614]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Не надо агрессии :)
по поводу наследников - все наследники, A есть A то есть код верен и для них

Означает ли это, что select from A вернет и наследников класса А?
3 фев 05, 18:50    [1298673]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
2Alexey Rovdo
Тогда мне непонятно, в чем заявленное преимущество ООСУБД в плане модификации сущностей перед РСУБД. РСУБД как минимум не сложнее, а чем-то даже и проще.

Кстати, как будет проводиться тогда сравнение типов объектов? Ведь фактически (рассмотри мой пример) добавление атрибута означает создание другого класса. Пусть typeof - функция получения типа объекта
/*Старый объект, был сохранен до изменения структуры*/
A a_old = new A();

/*Новый объект, создается после изменения структуры*/
A a_new = new A();

if typeof(a_new) == typeof(a_old) {
...
};
Как такое будет работать?

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


В классическом ОО-программировании нет возможности переопределения классов по ходу выполнения программы. Я только могу привести фрагмент описания, который показывает, как в таком случае рекомендуется поступать (в учебниках по C++):

[b]Use Derivation Instead of Type-Fields[/b]
Suppose that you have to implement an internationalization helper class that 
manages the necessary parameters of every natural language that is currently 
supported by a word processor. A naive implementation might rely on type-fields to 
indicate the specific language that is currently being used (for example, the 
interface language in which menus are displayed).

class Fonts {/*...*/};
class Internationalization
{
private:
  Lang lg; //type field
  FontResthisce fonts
public:
  enum Lang {English, Hebrew, Danish}
  Internationalization(Lang lang) : lg(lang) {};
  Loadfonts(Lang lang);
};

Every modification in Internationalization affects all its users, even when they are 
not supposed to be affected. When adding support for a new language, the users 
of the already-supported languages have to recompile (or download, which is 
worse) the new version of the class. Moreover, as time goes by and support for 
new languages is added, the class becomes bigger and more difficult to maintain, 
and it tends to contain more bugs. A much better design approach is to use 
derivation instead of type-fields. For example

class Internationalization //now a base class
{
private:
  FontResthisce fonts
public:
  Internationalization ();
  virtual int Loadfonts();
  virtual void SetDirectionality();
};
class English : public Internationalization
{
public:
  English();
  Loadfonts() { fonts = TimesNewRoman; }
  SetDirectionality(){}//do nothing; default: left to right
};
class Hebrew : public Internationalization
{
public:
  Hebrew();
  Loadfonts() { fonts = David; }
  SetDirectionality() { directionality = right_to_left;}
};

Derivation simplifies class structure and localizes the changes that are associated
with a specific language to its corresponding class without affecting others. 

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

А вот ваш второй вопрос действительно высвечивает ряд моментов, которые имеют место на практике. Разумеется, в каждом конкретном случае преобразования осуществляются по определенным правилам (в некоторых ситуациях индексы действительно могут стать препятствием). Описание всех этих правил и возможных вариантов поведения есть в документации на FastObjects. Приводить же здесь столь длинные описания вряд ли целесообразно.
3 фев 05, 19:00    [1298693]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest
Насчет запроса, да вернет всех наследников, но можно и без них, все настраиваемо.
Насчет агрессии ......... прошу прощения, погода просто сегодня замечательная и день спокойный :-)
3 фев 05, 19:08    [1298704]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Rovdo
Нет, пример на мой взгляд вполне удачный. И вот почему.
Я тоже сталкивался с подобной ситуацией. И сегодня подобная база построена так, как вы пишете, т.е. атрибуты и заголовки объектов разнесены.
Но вот сам состав атрибутов для разных объектов и типы объектов постоянно изменяются. Т.е. сегодня говорят ввести один атрибут, завтра вместо него появляется другой, послезавтра три атрибута удаляется, но появляется пять новых. Само по себе это не доставляет проблему - ну в чем собственно трудность - взяли да изменили состав атрибутов. Но оказывается, что нужно хранить всю информацию за предыдущее время. Т.е.. если у нас был определенный период, когда для объектов определенного типа существовал атрибут А, то вся информация, введенная в это время в базу, должна там оставаться. А вот это уже приводит к значительным издержкам, которые, разумеется, преодолимы и в рамках реляционной модели, но в случае использования ООСУБД это вообще не было бы проблемой.


Т.е. вместо того чтобы продумать систему хранения метаданных и менять только данные, а не структуру, Вы предлагаете на каждых чих создавать новые объекты, менять структуру базы? Если учесть что, как мы выяснили, структура данных в ООСУБД меняется ничуть не проще чем в РСУБД, то предложение несколько странное.
Lirik_SPB
Для ООП программиста это означает наследование и интерфейсы которые поддерживаются в объектной базе данных. Для программиста реляционных баз данных это означет заплаты для каждой новой структуры данных.

А вот не согласен насчет последнего - для него это будет просто редактированием данных(данных, описывающих данные).

И еще такой вопрос: при работе с ОО языками постоянно возникает проблема утечек памяти и обращений к несуществующим объектам. Есть конечно где-то автоматическая сборка мусора - но она не может работать когда приложение "размазано" по уровням - сервер не может знать какие объекты нужны клиенту. Т.е. перейдя на ООСУБД, я поимею еще и такую проблему?
4 фев 05, 01:05    [1299005]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Lirik_SPB
Разработка систем на реляционных базах данных подразумевает что один программист кодирует бизнес-логику, второй кодирует обращение к базе данных. Для объектных базах данных нужен только кодер бизнес-логики.

Я бы попросил как-то аргументировать. Неужели тот кто кодирует бизнес-логику не обращается к БД?
4 фев 05, 01:11    [1299007]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Но я то спрашиваю "как же он решает" , а у вас ответ на вопрос "как не решает". Я прекрасно понял, что с помощью Java не решает, вот и все ...
И посему еще раз конкретизирую.

Что пользователи разработанных вами информационных систем используют для получения или складывания данных в БД ? Обращаю внимание, "что используют", а не "что могли бы использовать в зависимости от постановки задачи".


А Вы читайте внимательней ответы на свои же вопросы:
c127> Как именно - зависит от постановки, .... Заранее невозможно сказать как именно заполняется база.

Повторяю еще раз: заранее невозможно сказать. Это то же самое что не сформулировав задачу требовать от разработчика структуру классов.

>Именно этот конкретный код можно запускать в QA ? Попробуйте - раскажете о результатах, заодно познакомитесь с MS SQL Server.

Да, именно этот код очень хорошо запускается в QA, в той части, которая требуется по условию задачи, поставленной Вами: "Дано: дата d, маршрут [Z1, Z2] Выдать таблицу (билеты в наличии): рейс - класс - кол-во мест". Только очевидно что 'нужная дата' должно быть заменено на нужную дату, а 'нужный рейс' на нужный рейс.

Еще раз спрашиваю: возражения по несоответсвию решения и постановки есть?

>Если вы являетесь разработчиком-практиком, то странно, что вы не понимаете что значит "чтоб оно работало". Демонстрирую пример претензии к вашему "теоретически верному" коду.

А вот если Вы являетесь разработчиком-практиком, то должны бы уже знать, что работать может по-разному: из командной строки, из ГУИ, какое окружение должно быть установлено (а у меня джавы нет, у меня Ваш код не работает) и т.д. Так что "чтоб оно работало" это пустые слова.

>А как узнать, что этот код действительно выдает то, что заявлено? Я вот, к примеру, не верю. Давайте убедимся на тестовом примере. Как это сделать?

Открою секрет: посмотреть на код и немного подумать. Вы же вроде знаете немного СКЛ, посмотрите на структуру БД и на запорсы, там же все ясно. Я, например, вижу что Ваш код тоже вполне рабочий, хоть и гораздо более громоздкий, но пытаться его запускать мне не приходило в голову.

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


Какие тесты, что вы несете. Тесты на пяти пассажирах, четырех рейсах и соединении двух таблиц (классов)? Ну если эти данные действительно позволяют протестировать FastObjects, то я уже представляю что с ней случится на миллионах записей.



>Лично я считаю постановку задачи вполне достаточной.

Раз постановка достаточна, то не затруднит ли Вас сделать одно из двух: либо признать решение SergSuper-а полным и удовлетворительным либо процитировать ту часть постановки задачи, которой это решение не удовлетворяет.

>А ваши претензии к параметрам, производным от реальной практической ситуации, совершенно надуманными.

Пардон, тут Вы кое-что подзабыли, это не мои претензии, это Ваши претензии:
Alexey Rovdo>Но в самом голом OQL или SQL тексте нет практического смысла - на практике всегда приходится писать приложение, которое отвечает за ввод параметров запроса и как-то обрабатывает полученные результаты. Вот в SQL-запросе 'нужный рейс' откуда берется? В Java программе я элементарно могу попросить пользователя ввести этот исходный параметр и поместить введенное значение в переменную. ... А SQL-запрос представляет собой лишь фрагмент, который иллюстрирует центральный алгоритм решения задачи, но не является полным решением.

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

>Меня вполне устраивает видеть в качестве решения чистый SQL-код, поскольку для любой ситуации я себе прекрасно представляю как и куда этот код помещать в приложении для работы с данными (т.е. лично мне совсем не обязательно видеть готовый код приложения, которое посылает SQL-запрос и получает от сервера запрошенные данные, чтобы оценить качество и эффективность обработки запроса), и я умею работать с QA.

Опять подзабыли, раньше говорили, что не устраивает и требовали готовый код:
Alexey Rovdo 28 янв 05, 11:50>справедливости ради нам нужно было бы рассматривать не чистый SQL-код, а код на Java, который посылает соответствующий SQL-запрос и получает результат.

>Но вот сравнение длины SQL-кода и длины приложения для FastObjects - совершенно некорректная операция.

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

Alexey Rovdo>Можно обсудить и эффективность работы разработчика - трудоемкость написания конкретного решения и т.п.

А чем мы занимаемся? В чем же тогда измеряется трудоемкость и эффективность (есть эмпирическое утверждение, что программист пишет одинаковое число строк кода в час независимо от языка), как не в количестве строк кода? Вот и получается, что у Вас программист работает в 4 раза больше, либо вместо двух программистов Вам нужно 8.

А интересно, что же Вы собирались сравнивать? Не собирались же Вы всерьез сравниваеть производительность баз данных на своих тестовых данных (5 строк в таблице, 5 объектов в классе)?

А ведь и правда, собирались:
>А меня вот больше интересует сравнение эффективности обоих систем (РСУБД и ООСУБД) при выполнении идентичных (по логике работы) задач (выборка данных, ввод и модификация данных).
4 фев 05, 03:28    [1299052]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 AAron

> Насчет маяков - есть разные способы хранения такого типа данных. Например, во всех нормальных СУБД (например, Oracle) есть поддержка XML, неструктурированные данные могут быть в XML, а описываться схемой. А дальше - дело техники.

Да не нужен никакой ХМЛ, все замечательно складывается в реляционные таблицы. ХМЛ это дерево, иерархичекие базы мы уже давно прошли. А вообще введение неструктурированных данных переносит проблему с разработчика структуры БД, которому в идеале вообще ничего делать не нужно, на разработчика логики приложения, но саму проблему не снимает и не упрощает. Их же пользователю показывать нужно в структурированном виде. Гибче структура - больше программирования.






2 Lirik_SPB

>Консоль это конечно замечательно, для vds вы
делаете кнопку в вашем приложении "Добавить аттрибут"
с кодом приведенным выше если это нужно.


И что потом с этим атрибутом будет делать приложение? Ни положить в базу ни показать пользователю, там же кроме кнопки ничего нет.

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

Спасибо, а то мы не знали. А еще к машине тьюринга. Это пустой звук.

>Другое дело эффективонсть разработки программы, ее дальнейшей работы и внесения изменений.

По эффективности разработки на приведенном примере пока имеем приблизительно четырехкратный выигрыш РСУБД. А чем короче код тем легче вносить изменения, так что тут РСУБД тоже опережают.

>А по поводу структуры данных я имел ввиду, что она неизвестна не только на в начале написания кода, а и после запуска программы. Проще говоря, программа запущена, а часть структуры данных поменялась. Насколько просто и безопасно можно это сделать с реляционной базой данных? В объектной базе данных это естественно.

В реляционной тоже, если подумать заранее. Есть куча ГИС-ов на РСУБД. Я знаю одну даже на парадоксе, там много чего можно менять в рантайм.

>Для ООП программиста это означает наследование и интерфейсы которые поддерживаются в объектной базе данных. Для программиста реляционных баз данных это означет заплаты для каждой новой структуры данных.

В Вашей терминологии для ООП программистов это заплаты в структуре классов.

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

Пока что получается что для ООБД в данной ситуации потребуется 8 кодеров.
4 фев 05, 04:06    [1299062]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 с127
Сюда же относятся Ваши рассуждения о сервере в вакууме. А почему отсуствие заполнения БД (которого по условию не требуется) это сервер в вакууме, а остсутсвие ввода параметров запроса это нормально? Давайте уже или откажемся от всего ввода-вывода (это моя идея и я на ней настаивал) или же включим в условие задачи полный ввод-вывод данных. Чтоб было честно.

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

Если положить решения SergSuper'а в какой-нить MS SQL, то на аксесе ADP клиент под него будет сделан за одну минуту и будет содержит ноль (0) строчек кода. Даже клавиатура не нужна. При этом обеспечивается и импорт данных, и интерфейс для ручного ввода данных, и вывод отчета хоть во внешнее файло, хоть на принтер, хоть по мылу автору вопроса, и запрос входных параметров - и все это без увеличения длины исходного решения SergSuper.
4 фев 05, 05:22    [1299079]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest
SergSuper
Lirik_SPB
Разработка систем на реляционных базах данных подразумевает что один программист кодирует бизнес-логику, второй кодирует обращение к базе данных. Для объектных базах данных нужен только кодер бизнес-логики.

Я бы попросил как-то аргументировать. Неужели тот кто кодирует бизнес-логику не обращается к БД?


Тот кто кодирует бизнес-логику, по-моему мнению, не должен думать о том как извлечь данные. Для программиста, работающего с объектной базой для выполнения запроса "хочу объект(объекты) данного класса", достаточно сказать "дай объект(объекты) данного класса", с реляционной базой данных, подразумевая запрос "хочу объект(объекты) данного класса" надо сказать "создай массив объектов, выполни запрос к базе данных, первый столбец запихай в первое поле, второй во второе поле и т.д. " . С получением условных выборок тоже подобные проблемы
4 фев 05, 12:04    [1299820]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ё..... пперный театр!!!

Такое ощущение - уж извините, но из песни слов не выкинуть - что Alexey Rovdo пытался начать работать с РСУБД. Пытался - но не смог. Уж не знаю, в силу каких причин, но не получается у него в архитектуру обычной РСУБД и технологии к-с запихать практически любую систему, тем более сложную, где атрибуты объектов и.т.д. Там ведь структуру продумывать нужно - правда, это не так сложно, но кому как. И вот тут вдруг нашлась ООБД!!! И наступило щастте!!! Ничего думать не надо! Таблиц не надо создавать - вообще все само. Пиши объект со свойствами - бац, и он в БД. Как-то там, но это же не важно, об этом чего думать? Хошь удалить свойства - удаляешь, хошь добавить - добавляешь, прямо даже в ходе работы системы, причем это фактически изменение структуры, но это же ООБД, там же это все само!!! Думать не надо - ошибся? Да фигли там, удалил ненужные атрибуты, добавил нужные. Все само! И т.д. и т.п. Красота!!!
По сути, на ходу и во время всей жизни системы меняется физическая структура данных. Чего будет потом - а на фиг думать? Объекты на лету преобразовываются в другие типы - а плевать, быстродействие не наш путь.

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

=============
ЗЫ Вывод не относится к чьей-либо личности. это просто вывод.
Прошу не обижаться никого, но десятки страниц по поводу ООБД навевают именно такие мысли.
По поводу приведенных примеров якобы именно для ООБД - это специально, чтобы посмешить, или как? Примеры, уже десятки или сотни раз решенные на РСУБД и отлично работающие, выдаются как тяжело осуществимые на РСУБД??? А как вам идея атрибутов - вместо того, чтобы написать правильно методы работы с такими данными, предлагается физически менять их структуру при добавлении/удалении какого-то атрибута. Прекрасно! Но у нас весь интернет-магазин в части товаров построен на системе объектов и их атрибутов - это все делается без изменения физической структуры данных (смогли однако!!!).
==========
Да.... В общем, куды мы катимся.
ЗЫ Сумбурно высказался, но вот так вот получилось. Пятница, холодно..... :))

-- Tygra's --
4 фев 05, 12:06    [1299823]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
BaZa
Guest
tygra
Ё..... пперный театр!!!

Такое ощущение - уж извините, но из песни слов не выкинуть - что Alexey Rovdo пытался начать работать с РСУБД. Пытался - но не смог. Уж не знаю, в силу каких причин, но не получается у него в архитектуру обычной РСУБД и технологии к-с запихать практически любую систему, тем более сложную, где атрибуты объектов и.т.д. Там ведь структуру продумывать нужно - правда, это не так сложно, но кому как. И вот тут вдруг нашлась ООБД!!! И наступило щастте!!! Ничего думать не надо! Таблиц не надо создавать - вообще все само. Пиши объект со свойствами - бац, и он в БД. Как-то там, но это же не важно, об этом чего думать? Хошь удалить свойства - удаляешь, хошь добавить - добавляешь, прямо даже в ходе работы системы, причем это фактически изменение структуры, но это же ООБД, там же это все само!!! Думать не надо - ошибся? Да фигли там, удалил ненужные атрибуты, добавил нужные. Все само! И т.д. и т.п. Красота!!!
По сути, на ходу и во время всей жизни системы меняется физическая структура данных. Чего будет потом - а на фиг думать? Объекты на лету преобразовываются в другие типы - а плевать, быстродействие не наш путь.



Самое смешное, что отчасти, все что вы говорите правда...
НО! это говорит не о тупости разработчика, а о том, что обычному девелоперу не нужно думать о том, как работать с СУБДом, а писать свои код.
нужно сделать что-то хранимым - бац поставил персистент, засосалось в базу и все...
НО!! Это вовсе не значит, что так можно делать всегда. Конечно, есть случаи, в которых такой стиль написания приложения, требующего работы с хранимыми данными, НЕВОЗМОЖЕН. И с этим никто не спорит

tygra
если кто-то не понимает, как разрабатывать к-с системы на РСУБД

А я и не хочу этого понимать... я хочу писать бизнес логику, и делать хранимым, то, что мне нужно
tygra
если кто туп, что не может правильно продумать структуру системы (или вообще ничего продумать не может)

А я и не хочу мыслить реляционными понятиями, а хочу строить ОБЪЕКТНУЮ структуру
tygra
если кто окончил недавно институт, ничего не знает, но считает, что он крутой программер

Я не буду спорить с тем, что я недавно закончил инситиут... хм институт может быть оканчивали вы, а я окончил УНИВЕРСИТЕТ (СПбГУ). Может быть слышали о таком?
И именно то, чему меня там учили позволяет мне утверждать все это...
4 фев 05, 12:37    [1299951]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest
Утверждение tygra` а можно свести к фразе "зачем вам языки высокого уровня, ассемблер все может - пользуйтесь им и не выпендривайтесь, а если не хотите то и не суйтесь в программирование" если проводить аналогию с языками программирования.
4 фев 05, 12:46    [1299989]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Лох Позорный


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

Если положить решения SergSuper'а в какой-нить MS SQL, то на аксесе ADP клиент под него будет сделан за одну минуту и будет содержит ноль (0) строчек кода. Даже клавиатура не нужна. При этом обеспечивается и импорт данных, и интерфейс для ручного ввода данных, и вывод отчета хоть во внешнее файло, хоть на принтер, хоть по мылу автору вопроса, и запрос входных параметров - и все это без увеличения длины исходного решения SergSuper.


Пора немного вернуться к истокам дискуссии и напомнить некоторым то, с чего все начиналось.

Sp1Der
... почитал, все что могу сказать, мне так писать не по душе, я не говорю что это плохо, проcто мне больше импонирует делать это средствами ООП ... Возможно я решаю некоторые задачи не самым эффективным методом, но универсальность решения, конечно же требует жертв, разве не так? ...

SergSuper
... попробуйте решить какую-нибудь задачу на процедурных языках и на SQL и увидите насколько последнее проще

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

SergSuper
... Попробуйте решить хоть одну задачу ...

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

Alex.Czech
... Давайте сначала вы решите эту задачу с использованием ООСУБД без SQL ... , а потом мы (или я, если угодно) напишем SQL-запрос, делающий то же самое. И мы все вместе обсудим что проще и удобнее ...

Alexey Rovdo
... а вот при достижении определенного уровня сложности объектные методы становятся также вполне востребованными. Однако рассматривать чересчур сложную задачу здесь не удастся. Именно поэтому приходится подумать и предложить тему, которая с одной строны ...

SergSuper
Ну вот быстро сляпал. Я правда не понял чем отличается маршрут от рейса и эти понятия объеденил. Также не стал конкретизировать каждое место, просто учитывается их количество. В принципе это все можно, но появится еще пара таблиц, и дольше делать, и наглядность не улучшится. За правильность так же не ручаюсь, возможны ошибки ...

PArth
Ну и чего Вы доказали? Функциональность OQL на данный момент не так уж и отстает от SQL и постоянно развивается...
А вот как Вы все эти результаты будете "запихивать" в прикладные приложения, которые все чаще и чаще "чисто" ОО?


PArth
У меня, например, при реализации моих задач в объектной схеме сложность запросов значительно уменьшается - вполне достаточно простых select'ов и короткой навигации по ссылкам (а insert и update изчезают совсем...) В реляционной же реализации (моих задач) запросы гораздо сложнее...

SergSuper
... Собственно я ничего не доказывал, просто хотелось сравнить. Как на SQL делать примеров много, а на ООСУБД еще ни разу не было...

Parth
... Вы никак не можете снять "шоры" с сознания. Вы настолько привыкли, что данные (база) отдельно, а обработка (клиент) отдельно... На секунду представьте, что это не совсем так. Например, что клиент ничего (почти) ничего не знает о самом существовании БД, а просто разделяет все свои объекты на постоянные (persistent, которые собственно и хранятся в БД, причем, заметьте, вместе с методами) и транзитные (transient, существующие только во время работы клиента)...

Alexey Rovdo
... И как я не отнекивался (считаю, что тот, кто ставил задачу заведомо уязвим для критики и решения предлагать не должен), но все-таки прийдется предложить свой вариант... В предложенном решении на SQL ряд положений задачи были упрощены... В моем решении места и билеты будут индивидуализированы и пассажир сможет выбрать номер места, на которое он покупает билет. Предлагаемое мною решение создается на базе FastObjects t7. Я буду использовать Java ... отмечу, что не ставлю своей целью предложить наиболее оптимальное решение. Скорее наоборот - структура классов предлагаемая мною для сформулированной задачи даже несколько избыточна. Но раз уж меня вынудили самостоятельно демонстрировать решение моей задачи, то я использую это для демонстрации функциональности и возможностей FastObjects ... модель классов, предложенная мною, не является оптимальной. И я не хочу доказать в данном случае, что использование объектного подхода будет эффективнее, чем использование традиционных реляционных средств. Однако, я настаиваю на том, что оба подхода приблизительно равноценны и позволяют достаточно легко получить требуемое решение...

Gluk (Kazan) Этот листинг как минимум раза в четыре длиннее ...
c127 Ваше решение значительно, в разы, длиннее ...

Alexey Rovdo
... всякий раз, когда кто-то пытается сравнивать длину программы на Java с длиной SQL-запроса, я просто вынужден обращать внимание на то, что сферический сервер в вакууме не является иллюстрацией практической ситуации ... сравнивать только лишь работу и эффективность запросов ... Но здесь и лежит принципиальное отличие объектно-ориентированных систем от реляционных - использование OQL-запросов в ООСУБД, хотя и поддерживается, но является плохой практикой (к FastObjects это относится в полной мере). Действительно эффективные объектно-ориентированные приложения не должны осуществлять выборку данных по значению (во всяком, случае этого следует всячески избегать) – они должны использовать прямую навигацию, что реализуется в программах на объектно-ориентированных языках программирования ... Таким образом в ООСУБД отделение базы данных от приложения противоречит всей идеологии системы. Практика использования ООСУБД FastObjects показывает, что в большинстве случаев она находит применение именно как встраиваемая СУБД, а пользователи приложений, построенных на базе этой системы, на деле вообще могут не знать о наличии в ней базы данных как таковой...

c127
... А почему ООСУБД будет работать на этом запросе быстрее, да еще заметно?

Alexey Rovdo
...Перед тем, как сравнивать два этих запроса, прошу пояснить мне для какой конкретно СУБД написан запрос на SQL. Также было бы полезно привести к некому единому значенателю состав хранимых данных. Так у меня имя и фамилия хранятся раздельно, а в реляционной модели – вместе. Не то чтобы это имело определяющее значение, но так было бы удобнее...

c127
... Ладно, давайте рассуждать таким образом. Можно строить ООСУБД приложения (типа клиент-сервер) в виде Java+сервер, (C++)+сервер, C#+сервер, SmallTalk+сервер, причем где начинается сервер Вы сказать не можете. Так вычтите из этих систем Java, C++, C#, SmallTalk соотвсетсвенно и ту общую часть, которая останется назовите сервером. Его и будем сравнивать. Чисто формальный подход ...

Alexey Rovdo
... Собственно говоря трудности при стыковке ОО-приложений с классическими реляционными системами и запросами на SQL и явились основной причиной появления ООСУБД. Поэтому мне совсем не хочется отказываться от сравнения наших решений именно в тех аспектах, которые скорее всего покажут некоторые преимущества ООСУБД... Чтобы не заморачиваться с вводом выводом будем рассматривать отдельные процедуры ... Если подходить к вопросу с чисто теоретических позиций, то клиента, разумеется, убрать можно. Но я не сторонник такого метода. Все-таки на практике приходится работать с конкретными продуктами ....

Alexey Rovdo
... Java-приложение, работающее с базой MS SQL 2000, идентичное тому, что я написал ранее для FastObjects. Я слегка изменил SQL-модель, предложенную SergSuper и переименовал в ней поля для достижения максимальной похожести и идентичности состава хранимых данных с той ОО-моделью, которую я использовал в Java-приложении для FastObjects... Что же еще принципиально отличает этот код от кода для MS SQL? А то, что при написании этого кода вообще не был использован SQL. Т.е. разрабатывать приложения на FO могут программисты совершенно незнакомые с этим языком (достаточно знания ОО-программирования и любого из языков Java, C++ или C#)...

ARCRUS
... нужно рассматривать технологию в том контексте, в котором она есть (применительно к FastObjects - это сервер и клиент вместе). Теперь Вы нам привели зачем то Java код для решения MSSQL - честно говоря достаточно было написать просто запрос, откуда он будет выполнен - с Java, Delphi, или вообще внутри ХП - это дело третье ...

Alexey Rovdo
... Лично я с этим утверждение согласен и уже говорил об этом. Но уж больно некоторым понравилось критиковать мой код за его длину. Вот и пришлось уравнять условия... Короче - не значит проще, понятнее или эффективнее. Некоторым нравится сравнивать по размеру (мне не нравится) ...

Gluk (Kazan)
... Кстати, длина сравнивалась не просто так, а как источник потенциальных ошибок. ИМХО навигационный код больший рассадник ошибок, чем отлаженные SQL-запросы с примитивнейшим вспомогательным кодом ...

Alexey Rovdo
Это мнение многих противников ООП. Но многие сторонники ООП его не приемлют. Священные войны на эту тему бушуют уже давно. На мой же взгляд тут даже не о чем спорить - можно только обмениваться декларациями. Каждый имеет право на собственное мнение и выбирает тот инструментарий, с которым ему работать приятнее (я даже не говорю об относительной эффективности разных подходов, поскольку эффективность самого разработчика как профессионала здесь гораздо важнее)...

c127
...Почему же Вы предпочитаете переделывать решение SergSuper-а ... То, что СКЛ решение после Вашей доработки увеличилось по длине до ОО решения может говорить, например о том, что Вы не знаете СКЛ-я... КОД ПОЛНОСТЬЮ РАБОЧИЙ... А пока что четырехкратный выигрыш в длине кода по-прежнему на стороне СКЛ-я.

Alexey Rovdo
... А где я этот код ухудшил? Готов исправиться.
На мой взгляд я его привел в соответствие со своим решением по названиям полей и по составу хранимой информации. Или вы действительно считаете, что преобразование поля fio в таблицу, где имена и фамилии хранятся отдельно является в данном случае "недопустимым ухудшением".
Почему я изменял именно код SergSuper, а не свой? А потому, что код SergSuper не был готовым кодом и его все-равно пришлось бы переписывать, чтобы загнать в конкретное приложение на базе MS SQL...


c127
По-моему правильнее приводить Ваш код в соответсвие с кодом SergSuper-а, а не наоборот ...

Во-первых в Вашей постановке не сказано, чтоб оно работало (не очень понимаю что под этим подразумевается) ...

На этом прения о доводке кода SergSuper-а можно прекратить...

... Сюда же относятся Ваши рассуждения о сервере в вакууме. А почему отсуствие заполнения БД (которого по условию не требуется) это сервер в вакууме, а остсутсвие ввода параметров запроса это нормально? Давайте уже или откажемся от всего ввода-вывода (это моя идея и я на ней настаивал) или же включим в условие задачи полный ввод-вывод данных ...

... В чем же тогда измеряется трудоемкость и эффективность (есть эмпирическое утверждение, что программист пишет одинаковое число строк кода в час независимо от языка), как не в количестве строк кода? ...

...чем короче код тем легче вносить изменения...

... (и прочая демагогия) ...


В конце концов я не имею ничего против того, чтобы вернуться к той структуре, которую написал SergSuper. И в последующем, вероятно, мне прийдется подробно рассмотреть ее отличия от структуры, которую использовал я. При этом, однако, мы подробно рассмотрим все эти отличия и ограничения, которые они накладывают (продолжение следует ...).

Больше демагогией заниматься неохота. Поэтому я уж постараюсь побыстрее выложить именно анализ технических деталей обработки однотипной задачи (Запрос 1) в разных системах и выводы, которые я из этого анализа получу.

С уважением, Алексей Ровдо.
4 фев 05, 12:50    [1300010]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
c127
Я привел XML только в качестве примера, т.к. оппонентам скорее всего это покажется понятнее, чем "какая-то метаинформация, таблицы" )

Разумеется подходов м.б. множество :)

2 ООСУБД-приверженцам.
Следующие вопросы по поводу изменения структуры.
был Класс А и объект a_old класса А
Class A {
public long propertA;
public long propertB;
public function long mulAB() {return A * B;};
};

function main() {
A a_old = new A();
};

Так случилось, что интерфейс класса был расширен.
Class A {
...
public function long divAB {return A / B; };
};
function main () {
A a_new = new A();
}
Как поведут себя FO и VDS при вызове метода a_old->divAB()?
4 фев 05, 12:51    [1300015]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
FO не хранит методы в БД - это целиком вопрос самого приложения.
VDS позволяет это делать с помощь доп. средства VDS SQL, но в этом случае к методу фактически присоединяется хранимая процедура. Вписали новую процедуру, которая оперирует существующими у объекта полями - и она заработает вне зависимости от того, как к ней обращается приложение.
4 фев 05, 13:03    [1300063]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest
Вообще-то структура данных не изменилась, добавился метод, организация его подгрузки вполне возможна (если все это в runtime). Если программа перезапускается то здесь вообще никакой проблемы нет.
4 фев 05, 13:05    [1300077]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Подождите, вы утверждали, что хранятся версии объектов, а следовательно и версии классов тоже. Значит объекты a_new и a_old это объекты разных классов (насколько я помню в ООП нет такого понятия как версия класса и объекта). Можете рассказать, как работает механизм версионности?
4 фев 05, 13:48    [1300341]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Lirik_SPB
Guest
При сохранении объекта в базу пишется его версия и новая структура. Структуры друг о друге знаютю Если извлекается старый объект то потом сохраняется уже в новой версии, а методы выполняются на стороне сервера приложений или клиента.
4 фев 05, 14:30    [1300636]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
2Lirik_SPB
Это не ответ на вопросы.
Дальше, а как будут работать индексы, если объекты разных версий?
4 фев 05, 14:34    [1300650]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить