- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
def __get_column_names(table: str) -> tuple:
try:
with conn:
cur.execute("SELECT name FROM PRAGMA_TABLE_INFO(?)", (table,))
column_names = cur.fetchall()
except Exception as excpt:
print(excpt)
column_names = tuple(i[0] for i in column_names)
return column_names
def db_register_user(user_data: types.User):
"""
SQL запрос для внесения данных о пользователе
Args:
user_data: telebot User объект, содержащий словарь с параметрами пользователя
"""
user_data = user_data.to_dict()
column_names: tuple = __get_column_names('Users')
user_values = tuple(user_data.get(key) for key in column_names if key in user_data)
try:
with conn:
query = 'INSERT INTO Users cn'.replace('cn', str(column_names))+' VALUES (?,?,?,?,0,3)'
parameters = (*user_values,)
conn.execute(query, parameters)
except Exception as excpt:
print(excpt)
conn.close()
На сколько в такой ситуации .format не безопасен? Идея в том, чтобы не объебошится программисту в коде введя неверное значение колонки. Для этого имена колонок берутся из самой базы (есть мысль ещё и типы брать). Есть вариант реализации получше? Спасибо
Follow us!
Серьезно, не нужно делать кривое квадратное колесо
https://docs.djangoproject.com/en/4.1/topics/db/models/
Проблемы с твоим подходом:
1) Ты делаешь два запроса в бд когда можно делать один. Это увеличивает время обработки запроса и больше потенциальных точек отказа.
2) У тебя захардкожено 4 параметра в кверю если я правильно понимаю, то есть тебе все равно придется менять это место в коде когда захочешь поддерживать новую колонку.
3) Если ты будешь добавлять новые колонки не строго в конец таблицы, то рано или поздно ты знапишешь что-то не так. С твоим подходом, ты в принципе сильно повышаешь вероятность что-то записать не так.
4) Именнованные параметры намного лучше читаются в логах или инструментации твоей бд.
Есть и другой подход. Скажем, EF умеет генерировать схему по коду, но как правило схема получается не очень.
А например в Django модель хоть и описываеца на питоне, но всё равно четко отражает СУБД
- graphql вроде так же делает
Опровергаю. Есть бизнес-контракты, требования к самому приложению, есть апи, которое оно должно предоставлять. Обычно оно выражается в каких-то структурах-объектах и сервисах. И вот уже от них пляшет вообще всё остальное.
Ты можешь сделать АПИ сервиса леера в бизнес-терминах, а слой доступа к базе в терминах базы, а потом их склеить, не?
В продуктовой разработке ничего этого нет. Именно потому я за продуктовую разработку.