Comments 11
> Концепция DFD-описателей начинает проясняться, правда?
Поздравляю, вы изобрели ORM!
Вот вам небольшая подборка уже существующих вещей для вдохновления: stackoverflow.com/questions/74141/good-orm-for-c-solutions
Поздравляю, вы изобрели ORM!
Вот вам небольшая подборка уже существующих вещей для вдохновления: stackoverflow.com/questions/74141/good-orm-for-c-solutions
(В непонятках)
Здесь был комментарий примерно такого содержания:
«Спасибо. Если у меня — велосипед, то там, наверное, феррари?»
Не совсем понимаю, куда он делся.
Здесь был комментарий примерно такого содержания:
«Спасибо. Если у меня — велосипед, то там, наверное, феррари?»
Не совсем понимаю, куда он делся.
Как можно полноценно работать с БД без JOIN'ов? :)
И не очень понял, как в библиотеке обстоят дела с HAVING, с IN (на который сейчас куда больше похож ваш BETWEEN), выборками через временные таблицы, функциями типа GROUP_CONCAT да и вообще различными агрегирующими функциями? С базо-специфичными моментами типа TOP/LIMIT?
Ну и может я слишком олдскул/ретроград, но на мой взгляд чистый SQL куда читаемее, логичнее и понятнее. И проектировался как раз, чтобы быть простым и похожим на обычный английский язык.
И не очень понял, как в библиотеке обстоят дела с HAVING, с IN (на который сейчас куда больше похож ваш BETWEEN), выборками через временные таблицы, функциями типа GROUP_CONCAT да и вообще различными агрегирующими функциями? С базо-специфичными моментами типа TOP/LIMIT?
Ну и может я слишком олдскул/ретроград, но на мой взгляд чистый SQL куда читаемее, логичнее и понятнее. И проектировался как раз, чтобы быть простым и похожим на обычный английский язык.
> Как можно полноценно работать с БД без JOIN'ов? :)
Например, вызовом VIEW или PROCEDURE, где все это есть. :)
Вообще, да. С помощью QST полноценно с БД работать куда сложнее. Правда, мне пока нигде не понадобились JOIN'ы, IN'ы и HAVING'и (с GROUP BY'ями), поэтому их поддержки в библиотечке и нет. Но IN добавить элементарно, и, наверно, я внесу это в список самых ближайших изменений. Правильно, надо всего лишь в конструктор SqlField(QString, SqlValue, SqlValue, SqlFieldPurposes), отвечающий за BETWEEN, внести небольшие изменения, а именно еще один параметр между SqlValue и SqlFieldPurposes. И, разумеется, добавить новые функции в генератор. Получится что-то вроде этого:
typedef enum {bvf_between, bvf_in} BinaryValueFunctor
SqlField(QString, SqlValue, SqlValue, BinaryValueFunctor = bvf_between, SqlFieldPurposes = fp_where)
Имеющийся код даже переписывать не придется.
А страшные слова, как GROUP_CONCAT, TOP/LIMIT пока в библиотечке не ожидаются. Хотя, пожалуй, TOP/LIMIT сделать несложно.
> Ну и может я слишком олдскул/ретроград, но на мой взгляд чистый SQL куда читаемее, логичнее и понятнее. И проектировался как раз, чтобы быть простым и похожим на обычный английский язык.
Хм, да нет, достоинств SQL я не отрицаю. Вот только не место чистому SQL в C++ коде. Я как-то насмотрелся на такое у себя на работе, и у меня теперь к подобному физическое отвращение. QST — она пока маленькая.
Например, вызовом VIEW или PROCEDURE, где все это есть. :)
Вообще, да. С помощью QST полноценно с БД работать куда сложнее. Правда, мне пока нигде не понадобились JOIN'ы, IN'ы и HAVING'и (с GROUP BY'ями), поэтому их поддержки в библиотечке и нет. Но IN добавить элементарно, и, наверно, я внесу это в список самых ближайших изменений. Правильно, надо всего лишь в конструктор SqlField(QString, SqlValue, SqlValue, SqlFieldPurposes), отвечающий за BETWEEN, внести небольшие изменения, а именно еще один параметр между SqlValue и SqlFieldPurposes. И, разумеется, добавить новые функции в генератор. Получится что-то вроде этого:
typedef enum {bvf_between, bvf_in} BinaryValueFunctor
SqlField(QString, SqlValue, SqlValue, BinaryValueFunctor = bvf_between, SqlFieldPurposes = fp_where)
Имеющийся код даже переписывать не придется.
А страшные слова, как GROUP_CONCAT, TOP/LIMIT пока в библиотечке не ожидаются. Хотя, пожалуй, TOP/LIMIT сделать несложно.
> Ну и может я слишком олдскул/ретроград, но на мой взгляд чистый SQL куда читаемее, логичнее и понятнее. И проектировался как раз, чтобы быть простым и похожим на обычный английский язык.
Хм, да нет, достоинств SQL я не отрицаю. Вот только не место чистому SQL в C++ коде. Я как-то насмотрелся на такое у себя на работе, и у меня теперь к подобному физическое отвращение. QST — она пока маленькая.
Написанная библиотека для выполнения запросов в своем основании использует statements или обычные вызовы?
А чем автору не понравился QSqlQuery::bindValue?
Sign up to leave a comment.
QST: QsT SQL Tools, инструментарий для Qt