Найти - Пользователи
Полная версия: Момент подключения к базе
Начало » Базы данных » Момент подключения к базе
1
doubtpoint
Есть, например, класс Goods выдающий информацию из базы данных.

Когда принято делать подключение к базе данных?
1) В основной программе, а в объект передавать идентификатор подключения.
Допустим Goods имеет два разных подключения к базе(один к локальной с описание товаров, а другой удаленный к сладу) и тогда выносить логику выбора из класса некрасиво

2) Создавать подключение в __init__ и сразу сообщить основной программе о проблемах с подключением.
Но возможно, программе и подключение к складу не нужно в данный момент.
Плюс, в основной программе, несколько копий объекта и следовательно к базе может быть очень много подключений

3) Создать при вызове методов Goods, по мере необходимости. Тогда каждый запрос будет подключение/отключение, что создась большую нагрузку



py.user.next
doubtpoint
Есть, например, класс Goods выдающий информацию из базы данных.
Класс ничего не выдаёт. Класс описывает устройство каждого объекта, принадлежащего этому классу. Класс - это такое объединение одинаковых объектов в одно множество. Соответственно, у тебя может быть много объектов класса Goods, каждый из которых имеет собственное, индивидуальное взаимодействие с базой данных. И вот объект уже как раз и берёт и выдаёт информацию из базы данных. Но класс один и он ничего не делает, потому что его нет ни в памяти, ни во времени, а объектов этого класса много и каждый из них имеет место в памяти и время жизни, в течение которого его состояния меняются с одного на другое.

doubtpoint
Когда принято делать подключение к базе данных?
1) В основной программе, а в объект передавать идентификатор подключения.
Допустим Goods имеет два разных подключения к базе(один к локальной с описание товаров, а другой удаленный к сладу)
Подключением к базе данных может заниматься вообще другой объект. А каждый объект, описанный в классе Goods, может подключаться только к одной базе, которую ему подадут снаружи. И то ему подают эту базу данных не напрямую, а опосредованно, в качестве какого-то источника с данными. Объект класса Goods даже не в курсе, что это за источник и является ли он какой-то базой данных. Объект класса Goods просто знает про операции, которые можно совершать над объектом-источником. А объект-источник, в свою очередь, подключен к базе данных каким-то способом, которых может быть много. В том числе объект-источник может быть подключен вообще к нескольким базам данных одновременно. Никто об этом не будет знать. Просто операция над объектом-источником будет скрыто выполнять поиск в нескольких базах. А объект-клиент, выполняющий эту операцию над объектом-источником, просто будет получать данные и не знать ничего про то, откуда и каким образом эти данные получены.

Ты можешь подсоединить к объекту сначала одну базу данных, поработать с ней, а потом подсоединить к этому же объекту другую базу данных, поработать с ней, а потом подсоединить к этому же объекту третью базу данных, поработать с ней, и так далее. Для этого у тебя должна быть такая операция у объекта, через которую к нему можно подключить любую базу данных в любой момент. Соответственно, не нужно делать несколько соединений с разными базами данных в одном объекте. Надо просто подключать объект то к одной базе данных, то к другой базе данных. Также у тебя может быть два таких объекта, где первый подключен к одной базе данных, а второй ко второй базе данных. Их же можно и перенастраивать на другие базы данных в любой момент. И вот эти объекты, подключенные к разным базам данных, могут быть собраны в объекте-источнике как в едином источнике данных, которые можно запросить у него.

doubtpoint
3) Создать при вызове методов Goods, по мере необходимости. Тогда каждый запрос будет подключение/отключение, что создась большую нагрузку
Подключением к базе данных должен заниматься вообще другой объект. На нём же и лежит ответственность за снижение нагрузки при подключении к базе данных. Объект, работающий с данными из базы данных, просто должен общаться с объектом, который управляет подключением к базе данных, и получать от него объект для работы с базой данных и сохранять этот объект для работы с базой данных у себя в памяти.

Если уж ты взялся за классы и объекты, то у тебя должно быть соответствующее мышление. Не надо просто тупо в лоб подключаться к базе данных. Они могут варьироваться, они могут меняться, способы подключения к ним могут видоизменяться во времени. Очень глупо будет заносить в объект, который работает только с данными, информацию о 100500 возможных изменениях, которые могут произойти с самой базой данных. Там имя самой базы данных в СУБД поменяется и у тебя уже все объекты сломаются, хотя данные в базе данных никак не изменились.

Пример
  
>>> class Reader:
...     def set_db(self, db):
...         self.db = db
...     
...     def read(self):
...         return self.db.query()
... 
>>> class Connector:
...     def connect(self, address, user, password):
...         return DB(address, user, password)
... 
>>> class DB:
...     def __init__(self, address, user, password):
...         self.address = address
...         self.user = user
...         self.password = password
...     
...     def query(self):
...         return 'name=kate age=30'
...     
...     def status(self):
...         return 'db<a={}, u={}, p={}>'.format(
...             self.address, self.user, self.password)
... 
>>> reader = Reader()
>>> db = Connector().connect('https://host', 'u', '!@#$')
>>> reader.set_db(db)
>>> 
>>> status = db.status()
>>> print(status)
db<a=https://host, u=u, p=!@#$>
>>> 
>>> result = reader.read()
>>> print(result)
name=kate age=30
>>>
doubtpoint
Спасибо за ответ. Не понял а где в вашем коде Goods? Возможно я имел ввиду под Reader его(основной метод его получать информацию из базы).

 class Goods:
     def set_db(self, db):
         self.db = db
     
     def desk(self, item):
         return self.db.query('desk', item)
    
     def sell(self, item):
         if self.db.query('amount', item)>0:
            return 'отгружаем'
         else: 
            return 'нет на складе'
        
class Connector:
     def connect(self, address, user, password):
         return DB(address, user, password)
 
class DB:
     base = {
           'base': {'desk':{'apple':'яблоки','tomato':'помидоры' }},
           'sklad1': {'amount':{'apple':1,'tomato': 0 }},
           'sklad2': {'amount':{'apple':3,'tomato': 2 }},
     }
     def __init__(self, address, user, password):
         self.address = address
         self.user = user
         self.password = password
     
     def query(self, tab, item):
         return self.base[self.address][tab][item]
     
     def status(self):
         return 'db<a={}, u={}, p={}>'.format(
             self.address, self.user, self.password)
 
goods = Goods()
db = Connector().connect('base', 'u', '!@#$')
goods.set_db(db)
status = db.status()
print(status)
#db<a=base, u=u, p=!@#$>
 
name = goods.desk('apple')
print(name)
# яблоки
db = Connector().connect('sklad1', 'u', '!@#$')
goods.set_db(db)
result = goods.sell('apple')
print(' '.join ([result,name]))
#отгружаем яблоки
#db = Connector().connect('base', 'u', '!@#$')
#goods.set_db(db)
name = goods.desk('tomato')
print(name)
# Забыли переключить базу!!!!

Так неудобно, потому что основная программа, по смыслу, не должна заботиться о том на каком складе(базе) искать
py.user.next
doubtpoint
Не понял а где в вашем коде Goods? Возможно я имел ввиду под Reader его
Объект класса Goods должен выполнять операции над объектом класса Reader. Объект класса Reader получает информацию, а объект класса Goods работает с уже полученной информацией. Откуда объект класса Goods её получил, к нему относится вообще? Это не его дело вообще. А в это время каждый объект класса Reader подключается к своей базе. Соответственно, так можно общаться с несколькими разными объектами класса Reader, каждый из которых несёт свою личную ответственность за подключение к своей личной базе данных своим личным способом.

doubtpoint
Так неудобно, потому что основная программа, по смыслу, не должна заботиться о том на каком складе(базе) искать
Если бы ты умел строить объектные модели, у тебя уже давно бы сложилось всё в оптимальную картинку, в которую это можно сложить. Но так как ты не видишь состояний объектов, ролей объектов, обязанностей объектов, отношений между объектами, то ты и начинаешь всё упрощать под своё мышление, которое развито максимум до процедур. То есть вместо равномерно распределённой по разным объектам модели, ты просто всё стираешь и пишешь тупую в лоб процедуру, которая вот в таком виде тебе понятна. Reader не надо стирать, им надо пользоваться, не задумываясь о том, что находится за ним. Это свойство называется инкапсуляцией. Знакомо тебе такое понятие? Инкапсуляция нужна для того, чтобы писать большие программы.

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

Так что, прежде чем браться за это всё, подтяни мышление до соответствующего уровня. Это надо книжки читать, практиковаться, опыт набирать. Иначе ты так и будешь записывать всё в толстые тетради про любой процесс всего чего угодно, чтобы контроль над ним не потерять. А в это время делать программки за тебя будут другие дяденьки, потому что маленький мальчик просто ничего не могёт и от него ничего не дождёшься в конечном итоге. Только пачка тетрадей после тебя останется и всё. Пачка тетрадей == куча говнокода какого-то, который, естественно, не фурычит и который никто за тебя доделывать не будет.
doubtpoint
py.user.next
инкапсуляцией
Я как раз об инкапсуляции и задумываюсь задавая вопрос.

Пускай в Goods есть несколько Reader. Connector для них создается в основной программе или в Goods передавать информацию о логине и пароле для создания там?

py.user.next
doubtpoint
Я как раз об инкапсуляции и задумываюсь задавая вопрос.
А ты знаешь, что такое инкапсуляция? Я вот думаю, что у тебя искажённое представление о том, что это такое.

doubtpoint
Пускай в Goods есть несколько Reader. Connector для них создается в основной программе или в Goods передавать информацию о логине и пароле для создания там?
Объект класса Goods должен работать только с данными про товары. Он не должен знать вообще про существование каких-то там баз данных. Объект класса Reader должен только читать данные из уже подключенного источника. Он не должен знать, какая там система управления базами данных, как к ней подключаться, на каком она сервере или хранится ли она локально. Объект класса Connector должен подключаться к источнику с данными. Он не должен знать, что это за источник по своей структуре, база данных это или это файл на диске. Соответственно, должен ли объект класса Goods знать про какие-то там пароли? Да он вообще не знает, как вся эта хуйня устроена, от него это всё скрыто. При этом к нему когда обращаются, он так же от них скрывает, что он там делает с этими товарами и сколько он их там видит и через что он их видит. Вот это инкапсуляция. Она даёт возможность выращивать программу дальше в любой её точке. При этом ни один объект из уже созданных и функционирующих не будет понимать этого даже, что в какой-то части программы что-то там меняется.

То есть если ты вообще из программы вырезаешь базу данных так, что её больше не будет вообще, все объекты класса Goods об этом даже не узнают, а продолжают работать, как и работали.

Поэтому про какие пароли для объекта класса Goods ты говоришь, если его обязанности не имеют никакого отношения ни к каким базам данных? Он должен с уже полученными данными работать. Он их от кого-то получил, поработал с ними, а потом кому-то это дальше передал.

Я тебе ещё раз говорю. Ты не врубаешься вообще, о чём речь идёт. Что тебе там кажется, это просто тебе кажется. По вот этим твоим глупым вопросам “а где пароли для Goods должны быть, снаружи или внутри?” очень хорошо видно, что ты не прочитал ни одной книжки и с чего-то взял, что, не понимая вообще нихера, ты можешь писать в этой сложной парадигме, которая вообще не для новичков ни разу. Для неё нужно мышление иметь определённое, которое вырабатывается систематическими тренировками. И теории тоже нужно знать дохера всякой, это тоже никуда не девается. Так вот если ты прошёл какую-то говношколу очередную, которая рассказала тебе розовые сказки про то, какой ты теперь программист ООПшный после их какого-то там курса для лохов, растянутого на несколько месяцев, то вот теперь иди туда и там задавай свои тупые вопросы. И не забудь спросить там “а где мои деньги? что-то у меня ни одной программы после вашего курса написать не получается”. А может, ты просто видосики посмотрел и стал такой вумный. Надеюсь, там автор тоже не закрыл комментарии и ты можешь пойти туда и ему свои вумные вопросики позадавать.
xam1816
doubtpoint
Есть, например, класс Goods выдающий информацию из базы данных.
Расскажи что это за программа в целом, какие операции она автоматизирует,т.е будет делать без твоего участия.

Как вариант, можешь проделать каждую операцию сам вручную и отметить, какие последовательные шаги приводят к конечному результату.Запиши подробно на бумаге каждый шаг и возможные варианты на текущем шаге. Потом на каждый шаг напиши программу,скрипт, который делает этот шаг за тебя.Потом напиши кнопку, при нажатии на которую, скрипты выполнятся в нужной тебе последовательности и окно которое выведет результат работы каждого скрипта и конечный результат(типа лог файл).

Может оказаться так, что твоя задача укладывается в 3-4 функции и ООП будет избыточно для этого.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB