Hello, Sheridan, you write:

S> Приветствую, Mamut, вы писали:

S> M> А что, по твоему, «какая-то метаинформация, например, в XML»? А что, по-втоему, такое плагин, реализующий доп. функциональнсоть с помещением информации в дополнительные поля в БД?

S> ... или я не понял, о чем ты ...

Начнем с постановки задачи:

Так как поддержку каждой конкретной БД хочется сделать в дополнительных модулях, а также поддержку форумов — тоже дополнительными модулями, причем модуль форума не знает ничего об используемом модуле БД, то возникает вопрос — а какже всетаки хранить эту дополнительную инфу?

Это классический ORM. Мы абстрагируем объекты от базы данных, оставляя работу с базой на некий промежуточный уровень.

Почему? Потому что твое приложение будет максимум, что делать, это что-то такое:

IPlugin *rating = pluginFactory -> getPlugin('rating');

rating -> rate = 3;
rate -> save();

Все. Никаких SQL'ей, естественно.

Твой плагин, в свою очередь, будет делать что-то такое:

IDBTable *table = Application::getDB() -> getTable('rating');
table -> addRow('rate', this -> rate);
table -> commit();

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


ORM позволяет тебе описывать тебе модель твоих данных без оглядки на движок БД. Пример из Питоновского Джанго:

from django.db import models

class Reporter(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    email = models.EmailField()

class Article(models.Model):
    headline = models.CharField(max_length=100)
    pub_date = models.DateField()
    reporter = models.ForeignKey(Reporter)

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

rep = Reporter.objects.create()
rep.first_name = 'Mamut'
rep.last_name = 'Nespit'
rep.email = 'dmitriid@gmail.com'

rep.save()

article = Article.objects.create()
article.headline = 'Helo, world'
article.pub_date = datetime.now
article.reporter = rep  
article.save()

Этого достаточно. create, save — этим займется родительский класс models.Model


Это то, что тебе нужно — с одной стороны. То есть возможность описать структуру данных и возможность работы с этой структуррой, не думая о БД.



Но есть и обратная сторона медали. Это синхронизация структуры этой структуры данных и БД.

То есть тебе надо уметь сказать: «Взять данные о структуре тут и там и создать/обновить базу данных по этим параметрам».

Для этого тебе нужен механизм migrations, популяризованый в Ruby on Rails.

Полупсевдопример, как это должно работать:
Начало:

--- model User ---
name = charfield
surname = charfield
------------------------

> syncdb User
... creating table user
... creating column name, surname
... updating index for user
... done.

Две недели спустя:

--- model User ---
name = charfield
surname = charfield
age = intfield
------------------------

> syncdb User
... table user exists, updating
... creating column age
... done.

И вот именно вторая часть, migrations, мало где реализована до конца и/или корректно. Потому что реализовать ее грамотно достаточно сложно.

А первая часть, ORM, вполне себе существует даже для С++.





ЗЫ. Вообще-то можно ORM и не трогать, если есть достаточно общий способ достучаться до БД из С++. То есть который позволит делать вызовы типа create_table, add_row и т.п. Но хз, есть ли такой. А вот DTL выглядит вполне кошерно. Осталось только миграции придумать...

ЗЗЫ. Кстати, многие объекты в Qt так и реализованы — поверх общего интерфейса к какому-нить QSQLProvider

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Наверное частый вопрос... Существуют ли для С++ кроссплатфоменные библиотеки для генерации sql под разные БД? Хочется как минимум постгрес и мускуль.
S>Если нет — как можно решить следующую проблему?...
S>Пишется оффлайн — клиент для форумов, жж, прочего. Вобщем для общения на форумах древовидного типа. Основа понятна — форумы, сообщения топовые и дочерние, список пользователей, исходящие. В четыре таблички ложится замечательно. Но дальше начинается самое интересное. Дополнительнаяинфа. К примеру оценки тут.
S>Так как поддержку каждой конкретной БД хочется сделать в дополнительных модулях, а также поддержку форумов — тоже дополнительными модулями, причем модуль форума не знает ничего об используемом модуле БД, то возникает вопрос — а какже всетаки хранить эту дополнительную инфу?
S>Решение в лоб — дополнительное поле к каждой таблице для хранения там xml мне кажется будет довольно сильно тормозить.
S>Вобщем как бы вы поступили в данной ситуации?


Эта проблема называется ORM — Object-Relational Mapping. Частично ответ есть тут: http://stackoverflow.com/questions/74141/good-orm-for-c-solutions

Естественно, это — только часть проблемы, но значительная часть

Приветствую, Mamut, вы писали:

M> А что, по твоему, «какая-то метаинформация, например, в XML»? А что, по-втоему, такое плагин, реализующий доп. функциональнсоть с помещением информации в дополнительные поля в БД?

... или я не понял, о чем ты ...

Mamut пишет:
>

> ЗЗЫ. Кстати, многие объекты в Qt так и реализованы — поверх общего
> интерфейса к какому-нить QSQLProvider

А, кстати, в QT-то что-то такое и есть.
Но в любом случае придётся запросы 2 раза (N раз) писать,
и нужна будет либа, которая доступ к СУБД сводит воедино.

Приветствую!
Наверное частый вопрос... Существуют ли для С++ кроссплатфоменные библиотеки для генерации sql под разные БД? Хочется как минимум постгрес и мускуль.
Если нет — как можно решить следующую проблему?...
Пишется оффлайн — клиент для форумов, жж, прочего. Вобщем для общения на форумах древовидного типа. Основа понятна — форумы, сообщения топовые и дочерние, список пользователей, исходящие. В четыре таблички ложится замечательно. Но дальше начинается самое интересное. Дополнительнаяинфа. К примеру оценки тут.
Так как поддержку каждой конкретной БД хочется сделать в дополнительных модулях, а также поддержку форумов — тоже дополнительными модулями, причем модуль форума не знает ничего об используемом модуле БД, то возникает вопрос — а какже всетаки хранить эту дополнительную инфу?
Решение в лоб — дополнительное поле к каждой таблице для хранения там xml мне кажется будет довольно сильно тормозить.
Вобщем как бы вы поступили в данной ситуации?

Приветствую, Mamut, вы писали:

M> Эта проблема называется ORM — Object-Relational Mapping. Частично ответ есть тут:

Мне не нужно отражать бд в объекты. Мне нужно просто построитель ddl и sql для разных движков БД на основе какойто метаинформации, ну например на основе xml

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Наверное частый вопрос... Существуют ли для С++ кроссплатфоменные библиотеки для генерации sql под разные БД? Хочется как минимум постгрес и мускуль.
S>Если нет — как можно решить следующую проблему?...

Если именно так, то ответил Mamut.

S>Вобщем как бы вы поступили в данной ситуации?

Выбрал бы одну БД и писал для нее. Универсальные решения одновременно для разных БД работают обычно посредственно. Это плата за универсальность.

S> M> Эта проблема называется ORM — Object-Relational Mapping. Частично ответ есть тут:

S> Мне не нужно отражать бд в объекты. Мне нужно просто построитель ddl и sql для разных движков БД на основе какойто метаинформации, ну например на основе xml


Это оно (частично) и есть. У тебя есть модель данных, которую надо прозрачно проецировать на БД. Это — отражение обхектов/сруктур данных в БД. Помимо этого, тебе нужен инструмент, который реализует поверх этого migrations, то есть изменение базы данных при изменении метаданных.

Первое для С++ есть. А вот второе — хз. Я пошукал по Гуглю и не нашел.

Пока задал вопрос на http://stackoverflow.com/questions/1276420/rails-migration-for-c

___>Здравствуйте, Sheridan, Вы писали:

___>Выбрал бы одну БД и писал для нее.

Действительно. Зачем в твоем случае (оффлайн-клиент для форумов) "кросс-БД", чем оправдано? Поддерживать ведь замучаетесь. Я имею в виду прежде всего поддержку пользователей.

Приветствую, Mamut, вы писали:

M> Это оно (частично) и есть. У тебя есть модель данных, которую надо прозрачно проецировать на БД. Это — отражение обхектов/сруктур данных в БД. Помимо этого, тебе нужен инструмент, который реализует поверх этого migrations, то есть изменение базы данных при изменении метаданных.
Мамут, мне не надо отображать бд в объекты. Не надо. У меня нет модели данных.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Mamut, вы писали:

M>> Это оно (частично) и есть. У тебя есть модель данных, которую надо прозрачно проецировать на БД. Это — отражение обхектов/сруктур данных в БД. Помимо этого, тебе нужен инструмент, который реализует поверх этого migrations, то есть изменение базы данных при изменении метаданных.
S>Мамут, мне не надо отображать бд в объекты. Не надо. У меня нет модели данных.

А что, по твоему, «какая-то метаинформация, например, в XML»? А что, по-втоему, такое плагин, реализующий доп. функциональнсоть с помещением информации в дополнительные поля в БД?

Sheridan пишет:

> Наверное частый вопрос... Существуют ли для С++ кроссплатфоменные
> библиотеки для генерации sql под разные БД? Хочется как минимум постгрес
> и мускуль.

Вообще говоря, нет. Частично же проблему решает, например, ODBC.

> Если нет — как можно решить следующую проблему?...

Вообще, если тебя интересует только 2 СУБД, тут можно
просто удвоить код запросов, для каждой -- свой.

Ну и, конечно, если одинаковые и универсальные, можно не
удваивать.