C++ как правильно работать с БД

c++ db orm

Тонко.

А то не хотелось бы зашквариться созданием запросов конкатенацией строк как в каменном веке %)

юзай printf и перестань комплексовать ^_^

Наверное, имелся в виду snprintf?

ну да, разумеется :)

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

юзай printf и перестань комплексовать ^_^

молодец, покажи короткий путь к SQL/NoSQL иньекциям

Ынтерпрайз желает использовать использует
Какие решения такого типа самые кошерные для С++?

Embedded SQL. Да, ынтерпарайз в продакшене использует овно мамонта 15-летней давности - именно оно обрабатывает транзакции по кредитным картам и т.п.

Переходи на JAVA и не парься. Там отлично проработанных фреймворков как гуталина на гуталиновой фабрике.
На плюсах для БД с вероятностью 100% получится очередное ущербное поделие. И это к личности не имеет отношения.

Мне нужно средство управления памятью и процессором (для числодробления трехмерного объекта, в воксельном виде загнанного в фиксированный объем RAM), а таким средством является C++.

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

Например, мой тестовый сервер - это одноядерный с гипертрейдингом Celeron 2,4GHz пятилетней давности с 2 гигами рамы. Попытка поднять на этом любой self-contained жава-фреймворк оборачивается мгновенным фейлом уже через несколько пользователей онлайн. В то время как грамотно написанный код на ненавистных крестах сможет держать _тысячи_ пользователей онлайн даже на таком убогом железе.

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

Вот теперь задача понятна. Да JAVA прожорлива по ресурсам, и для вашей задачи не пригодна. Что-то надо искать на плюсах.

Может Qt?

настоящие мужики пишут свой ORM. особенно плюсисты.

QtSql - не ORM

Соси! В смысле, http://soci.sourceforge.net/

классика

интересный вариант, спасибо

Спасибо!

Соси!

только хотел поздравить человека, который на ЛОРе осмелился выражаться правильными словами :3

http://cppcms.com/sql/cppdb/

Не ORM, но, возможно, тебе подойдет.

Ынтерпрайз

Тебе надо написать аппликуху на C++, которая будет динамически в 120 потоках формировать SQL запросы, слать их через CORBA в распределённое Java-приложение на солярисе, которое будет через зашифрованный канал общаться с Oracle, а потом отдавать результат тебе обратно через CORBA. По другому никак.

А по сабжу, пишешь класс для формирования запросов и всю возню со строками в нём инкапсулируешь:

Query q(Query::from(penis_data));
q.addWhere("length >= 30");
q.addWhere("width >= 10");
QueryResult res = q.execute();

А внутрях хоть std::stringstream, хоть snprintf, хоть собачий член, что твоя душа пожелает.

Да это-то тупняк, лол. Интересное начинается, например, с тредпула и кэширования запросов, кэширования результатов запросов. Интересно lazy-подсасывание полей в объекты, зная что объекты персистятся в БД и могут быть частичной комбинацией таблиц и вызовов хранимых процедур. Наследование классов и связанное наследование таблиц. И чтобы оно еще было переносимо между разными БД. Надо написать целую магию, чтобы оно не тормозило (вспоминая внутренности Хибернейта, от которых стынет кровь). А тут еще и кресты. Посему неплохо бы, чтобы все это кто-то написал за меня =)

объективно нагруженный сетевой код на крестах будет стоить _значительно_ дешевле того же на Java.

Антон Кекс с тобой категорически не согласен. Иначе не стал бы переписывать Angry IP scan с C на Java.

Яков Сироткин — Холивар: C++ vs Java: http://www.youtube.com/watch?v=dx_6oVFuP8Y

Для тяжелых данных лучше избегать орм, они не магически умные и все четко закешируют. Лучше родной драйвер бд, пул соединений, prepared statements, batch insert и ручные кеши. И спец запросы, иногда даже спец индексы

Яков Сироткин — Холивар: C++ vs Java:

В итоге все свелось к тому что безтолковый С++ девелопер безтолковее толкового и безтолкового Java девелопера.

и «А зачем экономить память?»

Яков Сироткин — Холивар

Штоэта?

Я все не стал смотреть, потыкал рандомно. Предполагается что это видео доказывает превосходство Java над C++? Прикольно

безтолковый
безтолковее
безтолкового

Убиват!

Убиват!

жду пативена с грамманацы?

1) Prepared statements - обязательно
2) Можно попользоваться ODBC - не так и плохо, но можно будет обеспечить переносимость между базами. Код ниже рабоатет либо c TimesTen, либо с Postgres

static apn_id_t _id;
static apn_name_t _name;

STMT_PREPARE(stmt_get_apn_by_id, tt_pcrf,
        "SELECT FIRST 1 name FROM apn "
        "WHERE id=:id",

        "SELECT name FROM apn "
        "WHERE id=$1 LIMIT 1"
        );
TT_BIND_COL_VARCHAR(_name);
TT_BIND_PARAMETER_INT16(_id);
TT_PREPARE_DONE;

rx_retcode_t db_get_apn_by_id(apn_id_t id, apn_name_t name) {
    rx_retcode_t rc;
    _id = id;
    _name[0] = 0;
    CHECK_RETCODE_ERROR(rc = tt_execute_stmt_fetch(&stmt_get_apn_by_id));
    strncpy(name, _name, SESSION_APN_NAME_LEN + 1);
    return rc;
}

А в чем его аргументы? Он уже придумал, как написать на яве content-aware memory deduplication? Напоминаю: мы экономим сейчас именно на железе.

Он уже придумал, как написать на яве content-aware memory deduplication?

Множество ссылок на один объект — это и есть «дедупликация». И GC за этим очень пристально наблюдает, удаляя сам объект, на который не осталось валидных ссылок даже в составе «оторванного» графа циклических ссылок. ;)

а если объект не один? Например, есть трехмерный массив, «кубик». (В игре это «планета»). Узлы кубика - комбинация данных, «в этом месте есть руда», «в этом месте нет животных», «это место относится к зоне А», «это место относится к зоне Б», итп. (Которые в терминах крестов, кстати, можно сжимать в битовые поля и PODы). Он весит много, типа мегабайт и больше. С точки зрения честности, надо каждому игроку постоянно выделять по новому такому кубику. Да и сам мир состоит из тысяч кубиков, на которых живут боты вместо реальных игроков. Но тогда память тут же закончится вся. Для реалистичности, представим, что на сервере 2 гигабайта x86. Поэтому мы (как интернет-провайдеры) должны выделять место, которого у нас на самом деле нет и адски шарить его. Оптимистично считаем, что только 20% игроков дойдут до серьезных изменений в «кубике» относительно начала развития событий, и кубики можно создавать прототипным наследованием _объектов_ прямо в рантайме. Т.е. мы считаем, что новый кубик - это старый кубик, плюс некий дифф. Когда путь от прототипа до реализации слишком длинный - делаем посередине «снапшот» (можно будет накладывать диффы начиная с этого снапшота, а не с далекого-далекого прототипа). Иерархия диффов-снапшотов не обязательно должна быть линейной, а скорее как в Git. Теперь, например, (в сишной реализации) если в планету врезался метеорит, мы можем занулить биты от А до Б (там будет уничтожено все живое) или заранее сохранить последствия в некий memory overlay и мерждить его в памяти.

я не совсем понимаю, как эффективно реализовать это в Java. Сделать каждый воксель «кубика» объектом? Но это само по себе даст эпический оверхед. Плюс не поплохеет ли GC? Надо собирать не все, а собирать внутри контейнера («кубик») и управляемо вдоль его иерархии прототипного наследования.

Жесть какая. Кубики, объекты, наследование, гит. Ява еще. Зачем вот это все? Тебе нужно каждому игроку делать свой «мир»? Ну делай его тупо в файловой системе. Если хочется дедупликации - на ZFS держи. И раздавай по хттп, тем же нжинксом. Ну и клиенты тоже пусть по хттп общаются, уже написали тут.

Или это ты набрасываешь по привычке? Тогда не буду отвлекать

ORM, ActiveRecord, Object annotations

Не надо тянуть из java всякую гадость. Лучше взять http://www.garret.ru/gigabase.html