Russian Qt Forum

Всем привет.

Сразу скажу я новичок в Qt. Есть крупный проект который планируется переводить на Qt, возникает вопрос, использовать или нет QtSql. Кто с ним работал долгое время, расскажите какие траблы встречали, или хотя бы накидайте преимущества и недостатки. База находится в MS SQL Server 2005, достаточно крупная (я сам ей не занимаюсь, но именно я проталкиваю идею перевода на Qt, поэтому желательно заранее узнать все подводные камни).

Заранее всем спасибо.

Планируется переводить на Qt или планируется сделать кроссплатформенным?
Уточните крупный проект предоставляет доступ к чтению/записи в таблицы с помощью форм/таблиц/еще чего либо, предоставляет пользователю агрегированную информацию (отчеты/графики/еще что-либо).
QtSql я так понимаю через ODBC будете использовать? Говорят медленно, хотя я не пробовал.
Я считаю следует использовать QT MVC на основе своего SQL слоя.
Использовался ли в предыдущем проекте скриптовый язык?

Переводить на Qt с MFC (Исключительно перевод)


Доступ к базе для чтения/записи, причём временами очень активно (часть базы является шлюзовой для обмена сообщениями между разными комплексами)


Да, будет использоваться только ODBC. Со скриптовыми языками пока не определились.

ИМХО, лучше всего на дотнет перевести и с базой через ADO.NET работать - скорость в разы возрастает

а кто мешает использовать TDS... ??

Я тоже не рекомендую переходить на Qt. Постарайтесь выбрать инстурмент с наиболее богатым SQL слоем. Ну и по возможности более динамичный. Ну и кроссплатформенный. Ну и здесь остается java и чуть-чуть dotnet'а. Или Вам также необходим богатый набор виджетов?

Наверно я бы тоже предпочёл уйти на дотнет, но тащить платформу дотнет нам нельзя, такова политика партии (это даже не обсуждается)  :(

Да, нам нужен ОЧЕНЬ богатый набор виджетов

Можно поподробней ? ссылку например

На labs пробегал топик, что его уберут скоро, типа устаревший, есть odbc им можно пользоваться...

Тогда морду и логику в КуТях написать, а все что касается работы с БД отдать на откуп ADO.

ADO в C++ лучше чем ODBC API ?

Давняя моя аппликуха была реализована в 2-х вариантах - ODBS & ADO.
В ADO она работала быстрее (не могу сказать что кардинально, но прирост был) Было очень много мелких и частых запросов.

Delphi не катит?. Билдер накрайняк. Тут и ADO есть и direct SQL и ОЧЕНЬ богатый набор компонент и заточенность под БД и ОЧЕНЬ навороченные генераторы отчетов и прочая, прочая, прочая. Но IDE платное, компоненты тоже.

Delphi и Borland тоже отпадают, такова политика партии (партия у нас жёсткая  ;D, говорят что это отмирающий продукт, спорить ни с кем не буду, и прошу не разводить на эту тему холиваров, это не моё мнение)

Всё таки кто много работал с QtSql может напишет с их точки зрения недостатки и достоинства - скорость доступа, удобство.

скорость через ODBC-драйвер такая же как и через ODBC.
Проблемы будут при работе с разными типами данными в виде:
* точность отображения делегатами одна, а точность при редактировании другая
* могут быть проблемы с доступом к таблицам имена которых регистрозависимые
* ещё всякое, на первый взгляд мелкое, но на практике очень неприятное.

* модели, представленные в QtSql перезагружают все данные при малейшем редактировании
* нужно будет разрабатывать свои делегаты
* для того, чтобы пользователь мог настраивать под себя таблицы (колонки двигать и т.д.) необходимо будет постараться
* для печати таблиц необходимо будет писать свою функцию
* Вы хотите все однотипные формочки ввода, таблички на c++ писать?

Обсуждаем, но скорее всего да

спорно... к примеру в QSqlTableModel есть кэширование....
зависит от сложности задачи.... в большинстве случаев не обязательно...

>>* модели, представленные в QtSql перезагружают все данные при малейшем редактировании
да, если стратегия не "ручная".

Я размышлял насчет ручной стратегии. При использовании ручной стратегии нужно где-то делать commitAll() или предоставлять данную функцию пользователю. И это дополнительная логика (расходы). А если мы пользователю предоставляем две-три связанные таблицы на форме, нужно делать мини-тулбар над каждой таблицей, или одну большую кнопку "сабмит" на все? Допустим тулбар. Значит нужно разработать виджет таблица-тулбар (расходы). А если делать одну большую кнопку (скажем какой-то базовый шаблон, класс), а в последствие понадобиться "хитрая" формочка, то получаем негибкость (расходы).
QTableView (многостолбцовая сортировка, фиксация столбцов, сокрытие/показ столбцов) - это функции, которые легко реализовать, но необходимо грамотно предоставить пользователю. Для многостолбцовой сортировки предется писать свою модель, и лучше не прокси.
И это мы еще не касались QDataWidgetMapper, который стоит немного особняком. И к которому скорее всего необходимо будет писать делегаты. И тулбар к QDataWidgetMapper писать надо.
И вот мы вроде сделали мини MS Access. А теперь давайте писать формочки на c++. И предусмотрим для них возможность сохранения состояния всех виджетов. Напишем некоторый менеджер формочек и предоставим их пользователю.
А теперь давайте сделаем отчет....И единственный вариант, который очень хорош собой - это NCReport, который вроде стоит ~ 400 ойро, что для фирмочки и недорого, но все равно расходы. Хотите сделать отчеты самостоятельно, необходимо создать некоторую yaml, xml для хранения описания струкутуры и некоторый рендерер. Можно использовать QTextDocument/View, это будет дешево и сердито. Ну графический дизайнер - это уже по желанию.
Ну и сводные таблицы, для которых как минимум понадобиться своя модель, как максимум свое представление. Создание сводных таблиц средствами ms sql диалекта я не рассматриваю.
И давайте теперь откроем Microsoft Access, и помоему я еще не все назвал...
P.S. Слегка сумбурно написал. В целом мысль такова: в плане front-end'а Microsoft Access мощнее чем QtSql + QtGui.

описанная вами история слабо вяжется с принципами ООП...

Хорошо же вы сравниваете Access и Qt...

GraninAS, а это всё под винду только должно работать? Если да, может C# и Ko?
Почему web-интерфейс не канает?

QtSql только для простых вещей. Если надо кроссплатформенно и местами не odbc, можно в сторону otl посмотреть, но тогда все модели руками, хотя для проекта сложнее записной книжки и так придётся их делать.

Access в попу :) (Наелся его уже. Нажмите пару кнопочек, там и там, и ваша база снова заработает. Поставьте сотню либ нужной версии, и тогда ваши формочки заработают.)
Для крутых отчётов есть JasperReports.

to Barmaglodd

C# и .NET вообще - более чем серьезная платформа. Я хоть на C# не пишу и даже близко не знаю его, по многим косвенным признакам понимаю, что вещь, по меньшей мере, хорошая. Вряд ли можно что-то придумать более подходящее для серьезной базы данных, чем MS C# + SQL Server. Но есть тут несколько оговорок. Люди обычно забывают, что Windows - не единственная платформа, а MS SQL Server - не единственный сервер баз данных. Промолчу об их немаленькой стоимости, поскольку это "общее место" в холиварах, каждый горазд про это сказать. Но вот что я знаю точно: существуют так же PostgreSQL, MySQL, Oracle, всякие Interbase и даже FoxPro, не к ночи будь помянут, а так же куча других вариантов. Писать же можно на чем угодно: C#, Qt C++, Delphi, Builder C++, Java, php, да хоть на asm под 286 процессор... Нет ни грамма смысла в спорах, что лучше, и что взять. Темы, подобные этой, появляются потому, что не хватает четких критериев выбора. Чтобы правильно задать вопрос, нужно знать большую часть ответа (Р. Шекли). То есть, составить список требований, и выбирать инструмент уже исходя из него. Ну вот некоторые пункты из возможных:

1. Кросплатформенность
2. Мобильность
3. Богатство сторонних библиотек и компонентов
4. Платность
5. Открытость
6. Актуальность
7. Простота в использовании
8. Порог вхождения
10. Личные предпочтения
11. И другое...

Так же ложна точка зрения, что если вы возьмете Delphi, то там всё уже украдено сделано до вас, а значит, писать будет просто и удобно. Как бы не так. Пусть у вас будет хоть трижды интеллектуальная RAD-система, без работы ручками у вас не получится ни одной большой программы. А если вдруг получится, то совсем не то, что хотелось бы. Не надо искать платформу, где все сделано за вас, а надо искать платформу, более всего подходящую под требования. Или писать на том, что известно вам лучше всего.

QtSQL, действительно, умеет мало что. А Qt? Так же как ADO-компоненты Delphi умеют мало что, зато сам Delphi умеет многое. Но это не повод их сравнивать. Помнится, в Delphi можно было писать кросплатформенные программки, где нижним слоем выступал как раз Qt. Наоборот: на Qt вы будете долго собирать компоненты по углам Интернета для вашей специфической задачи, проклиная все на свете, но зато перейдете на Delphi, - и компоненты расцветут аки цветы. Нет смысла в сравнении. Qt хорош. C# хорош. Java хорош. PHP хорош. Delphi, на худой конец, тоже хорош. Возьмите то, что нужно.

А вот Access, действительно, туда.

Спасибо за развёрнутый ответ :)
Я вопрос хотел задать топикстартеру, но почему-то ваш ник скопировал :)

to zerocool

QtSQL - часть Qt. Отсюда несколько важных преимуществ.
* Кросплатформенность.
* Предельно прозрачная архитектура. Более логичной системы мне еще не доводилось видеть.
* Удобство программирования.
* Богатые возможности.
* Да куча других преимуществ!..

Отсюда же несколько важных недостатков, выше уже кое-что расписали, дополнять не буду. Не в том дело. Дело в двух моментах:
- На любой, даже самой продвинутой платформе, можно написать полное г.
- На любой, даже самой захудалой платформе, можно написать шедевр.
Но Работы ручками не отменит ничто и никогда.

Я догадался :) Пожалуйста :)

Ну что же, раз access в попу, а и действительно в попу его.
Тогда давайте кинемся в другую крайность: python + pygtk. Наикроссплатформнейшая связка. Для python'а скорее всего есть драйвер. А вот он и есть http://code.google.com/p/pymssql/, который предоставляет db api 2.0.
Набор виджетов gtk чуть поменьше, чем у Qt. Однако сам пайтон предоставит все батарейки как у Qt и даже больше (имеется ввиду regexp, network (sockets, http, smtp),  xml, yaml и т.д.). На pygtk, как я уже говорил, написана система tryton, а точнее front-end к системе.

Python попахивает какой-то уже совсем большой специфичностью. У меня он ассоциируется с загогулистым матовым инструментом, который может быть повернут на нескольких шарнирах, но для чего все это нужно, - непонятно. GTK ассоциируется с зубодробильной установкой. Qt - с конструктором, который и в Африке конструктор.

А еще есть PyQt. Это, получается, все плюшки Pythona + плюшки Qt'а. Ядерное сочетание.

Из серверов БД я рекомендую PostgreSQL.

Согласен, если нужен переход  с одной базы данных на другую, то последняя должна быть Postgresql.
Хм, пайтон, загогулистый?
Чтобы портировать приложение с c++ на пайтон придется воспользоваться только клавишей DEL. Не берем сложные случаи.
GTK зубодробильна? Возможно на c и исключительно в целях большой портируемости в разные другие языки. На разных других языках GTK полностью или почти полностью использует дизайн языка. Хотя возможно Вы имели ввиду сами виджеты, их устройство?
В целом python + gtk далеко не самый богатый/мощный, но зато бесплатно-кроссплатформенный. Для postgresql правда драйвера чуть устарели или работают только под python3.
Касаясь PyQT, не случилось бы того же, что и с QtJambi. Кстати почему его свернули?
P.S. Уси плюшки Qt давно в пайтоне, от Qt нужны только красивые кнопочки, и всеми любимая поддержка стилей.

Не знаю. Может, это был эксперимент по скрещиванию монстров.

Ну, вот такие вот ассоциации. Но ничего хорошего или плохого ни про Python, ни про GTK я сказать не могу, я их попросту не знаю. Так что поверю вам на слово :)

"Пайтон"...

А если понадобится что-то посчитать? Я имею в виду банальные долгие вычисления, (почти) не связанные с вводом-выводом.

В поток их, либу какую математическую подключить, на CUDA / OpenCL загнать. И пущай себе считаются.

"Вычисления"...
...cвязанные с БД в триггеры, триггеры на си (postgresql позволяет), не связанные с бд в python модуль, пайтон модуль на си (python позволяет). В пайтоне в свою очередь используется объектная система проще чем в gtk. Почувствуете себя Страуструпом, который с++ еще только на макросах писал.
Возможно топикстартеру не стоит прислушиваться к данному мнению, потому что оно обойдеться дороже, чем Qt + MSSQL. C другой стороны вот скажите, можно ли для mssql писать триггеры на c?

На managed C++ можно. Или на Си-шап.

.Net, короче.

И триггеры, и хранимые процедуры, и функции (скалярные и табличные), и агрегаты, и свои типы данных определять.


Э... а вариант "просто  использовать С++" никак не рассматривается?

А что Вам вычисления обязательно в объекты оборачивать? А для биндигов с++ не подходит.

Не обязательно, конечно.

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

Зачем себе отказывать?

Это Вы про которые биндинги?

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

Рефлексия - штука полезная и приятная(и даже почти самодостаточная в своей ценности:)), согласен.

мимо проходил...
как раз на python+qt пишу себе Access (или Foxpro :) )
ГУИ, отчеты

до серьезной проверки еще дело не дошло, но кое-что работает

под Windows можно посмотреть:
http://www.penta.by/penta_pump.html (http://www.penta.by/penta_pump.html)

vallager, рассматривали ли Вы полный список Python GUI инструментов? Используете PyQtSql или db api 2.0? Как со скоростью выполнения?

смотрел Qt, Wx
выбрал Qt
сначала возился с зоопарком dbapi (pyodbc, mysqldb, pygresql)
задолбало, перешел на QtSql
но для работы с DBF все равно пришлось использовать pyodbc - в QODBC глюки
скорость:
таблица 1258554 записей, около 40 полей
MySQL , InnoDB - открывается в гриде через 24 сек, скролится без тормозов
если MyISAM - 6-7 сек
при герерации PDF  - 115 страниц/мин, RTF - чуть побольше