Доброго дня!
Наверно, “инфраструктура” слишком громко сказано)
Интегрировал в проект sqlite бд и создал небольшой модуль реализующий основные действия - CRUD. Теперь встал вопрос об удобстве использование сего в проекте.
Например, есть таблица с пользователями, для которой есть ряд столбцов: name, nick, role и т.п.
Для получения инфы из неё есть метод - get_user(name), который возвращает список словарей (где ключ - название столбца, значение - значение) по найденному имени. Из данного словаря по ключу забираем нужное значение. Тут возникает трудность, т.к. с проектом работаю не я один, а другие участники могут не знать структуру базы, да и самому каждый раз лазить, чтобы вспомнить точное название столбца такое себе. Варианта вижу два:
1. Описать доп. модуль для каждой таблицы, для каждого столбца (решение прямо скажем полное минусов, во-первых, из-за трудоемкости, во-вторых, в случае изменения структуры опять же менять кучу методов)
2. Опять же описать доп.модуль, но описать названия столбцов в виде переменных, в методах уже ими оперировать, решение чуть приятнее и в случае изменения структуры менять только значения переменных.

Есть ли иные более приятные решения, либо подходящие паттерны?
Надеюсь все дожили до конца этого трактата)

Artegr
чтобы вспомнить точное название столбца такое себе

1 проблема не очень ясна. Приведите пример что вы имеете ввиду под “списком словарей”.
Я не вижу проблемы посмотреть поля.
Да, объект надо получить чтобы посмотреть поля. Это естественно, поскольку как еще инфу из базы взять.

Artegr
Есть ли иные более приятные решения,

А мне ваши решения непонятны. Ну сделали вы модуль. А как это помогает работать?

1. Самое адекватное решение - поддержание актуальной документации по проекту, это вам ничто не заменит. Не менее важно грамотное проектирование базы. Если вам сложно вспомнить имя столбца то точно у вас с базой что-то не так.
2. Можно взять базу поближе к языку (ZODB, Mongodb) В NoSQL с миграциями попроще.
3. Проверенное годами решение это использование sql алхимии.
4. В сложных случаях кодогенерацию никто не отменял. (вам в любом случае нужен инструментарий обеспечивающий миграцию с одной схемы базы на другую).

Artegr
Интегрировал в проект sqlite бд и создал небольшой модуль реализующий основные действия - CRUD.

Теперь то, насколько легко ты её в своём проекте можешь заменить на другую систему управления базами данных, даже на noSQL, не меняя в своей программе ничего особо, - это и есть показатель того, насколько хорошо написан твой код. Если не можешь и топором вырубить теперь из программы SQLite-базу, то явно у тебя слишком много лишних связей в коде.

То, что тебе нужно куда-то там лазить и другим нужно понимать структуру базы данных, чтобы ей пользоваться, говорит о том, что не слишком правильно ты код написал. Ты должен сделать интерфейсы, а уже к какой СУБД они будут привязаны, никого не должно волновать; они должны просто пользоваться твоей программы, даже не зная, какая там база и с какой структурой под капотом.

Судя по написанному вы хотите ORM, как примерdoza_and уже озвучил SQLAlchemy

py.user.next
То, что тебе нужно куда-то там лазить и другим нужно понимать структуру базы данных, чтобы ей пользоваться, говорит о том, что не слишком правильно ты код написал. Ты должен сделать интерфейсы, а уже к какой СУБД они будут привязаны, никого не должно волновать; они должны просто пользоваться твоей программы, даже не зная, какая там база и с какой структурой под капотом.

Вот как раз из-за этого я и понял, что что-то не так)
Тоже подумал насчет ORM, но пока выбрал peewee. Всем спасибо)