QtSQL преимущества и недостатки

[zerocool]

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

[lit-uriy]

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

[asvil]

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

[zerocool]

* Вы хотите все однотипные формочки ввода, таблички на c++ писать?

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

[crossly]

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

спорно... к примеру в QSqlTableModel есть кэширование....

* нужно будет разрабатывать свои делегаты

зависит от сложности задачи.... в большинстве случаев не обязательно...

[lit-uriy]

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

[asvil]

Я размышлял насчет ручной стратегии. При использовании ручной стратегии нужно где-то делать 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.

[crossly]

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

[GraninAS]

Я размышлял насчет ручной стратегии.

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

[Barmaglodd]

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

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

[Barmaglodd]

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

[GraninAS]

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, действительно, туда.

[Barmaglodd]

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

[GraninAS]

to zerocool

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

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

[GraninAS]

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

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