Название: Что выбрать для SQL таблиц? Отправлено: phpCoder от Февраль 15, 2015, 11:51 Добрый день.
Подумываю о создании класса для модели для представления данных из БД (сейчас использую QTableWidget). Встроенный класс в Qt мне не подходит. Может быть среди Qt-шников есть некий устоявшийся подход для создания модели таблицы? Определенный набор классов... Название: Re: Что выбрать для SQL таблиц? Отправлено: Kurles от Февраль 15, 2015, 13:49 Встроенный класс в Qt - это QSqlTableModel? Чем он не подходит?
Название: Re: Что выбрать для SQL таблиц? Отправлено: phpCoder от Февраль 15, 2015, 14:07 Хочу свои делегаты, чтобы они по своему редактировали и оформляли после редактирования ячейку. Тем более данный класс, как я понял, годится только для просмотра/редактирования плоских таблиц. Если запрос сложный с обилием JOIN, то нужно свою модель.
Название: Re: Что выбрать для SQL таблиц? Отправлено: Termit от Февраль 15, 2015, 14:56 Хочу свои делегаты, чтобы они по своему редактировали и оформляли после редактирования ячейку. Тем более данный класс, как я понял, годится только для просмотра/редактирования плоских таблиц. Если запрос сложный с обилием JOIN, то нужно свою модель. QSqlQueryModel поддерживает запросы любой сложности. Название: Re: Что выбрать для SQL таблиц? Отправлено: Kurles от Февраль 15, 2015, 19:32 И делегаты к модели можно прикрутить любые.
Название: Re: Что выбрать для SQL таблиц? Отправлено: unkeep от Апрель 02, 2015, 11:39 Я бы посоветовал не мешать вью модель с логикой по работе с бд.
Такой вариант уместен в простых\тестовых случаях. Он чреват трудностями масштабирования. А из попытки сделать что-то универсальное вряд-ли выйдет что-либо путное. На мой взгляд лучше сосредоточится на разработке отдельных классов для манипуляции данными в бд(шаблоны: активная запись, шлюз таблицы, слой доступа к данным), а qt вью модель использовать лишь как прослойку между представлением и этими классами(либо между представлением и слоем бизнес логики, который в свою очередь манипулирует бд). Название: Re: Что выбрать для SQL таблиц? Отправлено: Akon от Апрель 02, 2015, 22:30 Да-да. Поддерживаю. Крайне желательно бизнес-логику не связывать с SQL-слоем. Используйте дизайн с ORM. Я в свое время для ORM использовал либу ODB. Подход там следующий - в хэдере С++ класса используются специальные директивы (#pragma), связывающие поля класса с полями в БД, устанавливающие связи нежду талицами и т.д. Далее этот хэдер дополнительно обрабатывается специальным препроцессором, который генерирует дополнительный С++-код (очень похоже на то, что делает MOC), где уже будут SQL-инструкции конкретной СУБД (поддерживаются PostgreSQL, SQLite, MySQL,...). Допускаю, что какие-нибудь сложные запросы объединения с ORM сделать сложно или нецелесообразно, но у меня не было таких задач.
|