БД в Андроид

Добрый день!
Подскажите пожалуйста такую вещь:
У меня есть 3-ри класса... К примеру: Компания, Клиент, Услуги...
И есть необходимость хранить данные всех этих клиентов предоставляемых услуг и тд.
Вопрос: Для записи и чтения из БД данных, как правильно будет сделать, 1-н класс для работы с БД который будет работать со всеми данными и обслуживать все эти классы или же сделать каждому классу по отдельному классу для работы с БД...
На сколько я понимаю правильным должен быть второй вариант по принципу того: А что будет если количевство классов разрастется до десятков-сотен ну в таком духе... Но все таки решил уточнить потому как испытываю какие то сомнения.... и чувствую что где-то что-то упускаю....

0

по идее есть сущность которая может взаимодействовать с БД и есть объекты которые используя эту сущность могут например сохранять или читать или модифицировать себя в БД. таким образом видим что нужно сделать и то и то)

0

Видимо где-то вы меня не поняли это взаимоисключающие вещи на сколько мне видится...
Мы либо делаем гиганский класс который будет служить для работы с бд для всех сущностей приложения... что не очень красиво... или мы будем для каждого класса который хочет работать с бд отдельную сущность обслуживающую только данный класс и его взаимодействие с общей БД....
Просто тогда сущностей которые могут взаимодействовать с БД будет столько же сколько и классов которые хранят свои данные....
А это палка на двух концах... Ведь если делать так то сразу же нужно делать какую то синхронизацию что бы приложения не рухнуло.... когда один класс записывает а другой читать пытается....

Добавлено через 6 минут
Либо нужно делать так, что бы не было возможности одновременно пытаться делать и то и то... а это уже урезание функциональности... ведь грубо говоря пользователь выбирает услуги жмет кнопку отказаться... в этот момент открывается соединение с БД и через менеджер услуг поля таблиц и взаимосвязи начинают удаляться... и в этот момент пользователь может ведь перейти на соседнюю страницу где отображаются все возможные услуги... и там же этот же менеджер должен загрузить данные... карочи чет у меня логика храмает... Все правильно просто
Нужно сделать так что бы БДМенеджер(класс) ожидал пока будет доступ к БД, и уже потом черпал от тудава данные

0

Сообщение от alex1392 или мы будем для каждого класса который хочет работать с бд отдельную сущность обслуживающую только данный класс и его взаимодействие с общей БД

да, по правилам проектирования так и нужно делать. например, у вас есть файловая система. и есть классы. и объект каждого класса может быть записан или прочитан из файла. очевидно же что вы будете реализовывать эти вещи на уровне каждого класса - в каждом из них будет метод записи и чтения обращающиеся к одному общему объекту файловой системы. безусловно этот объект должен быть безопасным с точки зрения одновременного обращения

Добавлено через 2 минуты

Сообщение от alex1392 нужно делать так, что бы не было возможности одновременно пытаться делать и то и то

не видно проблемы. либо объект представляющий базу уже безопасен сам по себе (вероятнее всего ибо разработчики такого объекта не могут быть наивными глупцами) либо мы просто исключим одновременный доступ завернув обращения например в захват освобождение семафора

1

Во ) большое спасибо за дискуссию и подсказки И еще один момент, вот думаю между вариантом когда каждый класс содержит методы работы с БД.. и между вариантом когда для каждого класса есть отдельный класс обслуживающий его работу с БД... ну например:
class User{}
class DataBaseUserManager{}

Добавлено через 1 минуту
Ну и естественно какой-то appDBManager необходим который будет при старте приложения проверять в принципе существует ли база и тд..

0

зачем вам манагер для каждого класса? не совсем понимаю что вы в него запихаете? какова его нагрузка?

0

Небольшая путаница в голове из-за вопроса а где же тогда должна создаваться сама БД... ведь каждый DB(classname)Manager{} содержит различные сведения о таблицах ключах и тд, которые скрыты инкапсуляцией... и смысла дублировать данные противоречит принципам ООП и тд.. как же тогда лучше сделать...
Создать ДБМанагер(общий) который будет создавать БД и поочередно к каждому классу МАНАГЕР для каждого класса передавать управление да бы тот инициализировал свои таблицы... Опять таки глупо как то... ведь при добавлении сущностей придеться переписывать ДБМанагер

Добавлено через 3 минуты

Сообщение от vxg зачем вам манагер для каждого класса? не совсем понимаю что вы в него запихаете? какова его нагрузка?

Ну у него нагрузка весьма простая, запись данных, чтение данных, удаление данных связанных с этим классом и тд..
Что бы не засорять сам класс....
На сколько я понимаю сущность не должна записывать саму себя в БД, этим должна заниматься отдельная сущность обслуживающая взаимодействие данного класса с БД...

Это как с аддаптерами, можно в принципе и в самом классе накидать, но читаемость и многое другое страдает,..
Да и нарушает некоторые базовые принципы...

0

Сообщение от alex1392 Небольшая путаница

тогда с самого начала. например, вот у меня 1001 класс. и каждый класс содержит метод toString() и статический метод parse(String s). кроме того каждый объект при рождении получает уникальный ID. теперь, у нас есть база где три столбца ClassID, ObjectID, Content - в каждой строке "базы" соответственно: какого класса объект содержится, какой ID объекта, ну и содержимое объекта. все. любые движения (запись, чтение, модификация) умещаются в toString, parse + собственно объект базы + небольшой обвес который будет работать с ClassID

0

Добавлено через 20 секунд
Что-то в таком духе он будет содержать на сколько я это вижу

0

ну в таком ключе (если есть туча таблиц и в них узлом могут быть завязаны всякие поля) всю эту бороду конечно лучше хранить в манагере

0

Вот да, теперь последний вопрос, на уровне того что Должен быть еще и AppDBManager который будет в случае необходимости создавать базу данных, и на сколько я себе это вижу то будет передавать ссылку всем другим обьектам поочередно да бы каждый из них создал нужные таблицы в базе и связи которые ему необходимы..
AppDBManager будет передавать каждому Manager в цепочке ссылку на сойденение с БД и номер версии БД

Добавлено через 1 минуту
Про апдейт мне вообще страшно думать если вдруг будет такая необходимость... так что пока просто забываю про такие мелочи

Добавлено через 57 секунд
А общие таблицы связей типа Клиент/Услуга ,будет наверное создавать основной Манагер

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

0

alex1392, одна БД для всех классов, не зависимо сколько их будет, при условии что это будет оптимальный вариант. Даже если что то в будущим поменяется, например структура БД, то можно будет безболезненно её переделать, сохранив все данные в ней при помощи афтер, если не ошибаюсь .

0

Сообщение от semiromid alex1392, одна БД для всех классов, не зависимо сколько их будет, при условии что это будет оптимальный вариант. Даже если что то в будущим поменяется, например структура БД, то можно будет безболезненно её переделать, сохранив все данные в ней при помощи афтер, если не ошибаюсь .

Это вполне понятно ) мы немного не об этом ) БД то одна, таблиц много ) получается паутина, и выходит что манагеры каждого класса создают свои таблицы и связи в определенной очереди,
Вопрос который осталось решить, это кто будет создавать промежуточные таблицы соответствия (Id(User),Id(service)

Добавлено через 29 минут
Оригинальная вещь:
Да бы создать БД и все нужные таблицы для каждого ДБМанагера необходимо вызвать конструктор.. то есть создать его... Создать их! в правильной поочередности, то есть по сути мне нужен какой то МейнДБМанагер как я и говорил выше который их в правильной поочередности создаст и тем самым каждый из них проинициализирует БД своей таблицей.. после чего уже можно будет работать...
То есть получается что при запуске App У меня будет new MainDBManager(); а в нутри него будет собственно проверка база существует?
Если да то просто выходим и апп работает дальше если нет то идет вызов всех манагеров
new DBUserManager();
new DBServiceManager(); и тд....

Добавлено через 57 секунд
попровте пожалуйста если в моей логике есть погрешность, а если нету то скажите плиз что я правильно понимаю концепцию сия ) за ранее большое спасибо

Добавлено через 1 минуту
а да, new MainDBManager и всех вызовах внутри мы эти переменные ничему не приравниваем, что бы они были созданы и сразу же после выполнения создания БД вылетали в мусор

Добавлено через 3 минуты
а у самих манагеров будут статические методы чтения записи удаления, в нутри которых будет получение соединения с БД выполнение необходимых действий и закрытия соединения..

0

если очень хочется все-таки сделать ORM, прочитайте документацию например на TMS aurelis или любую другую реализацию ORM
имхо штука очень спорная
для задач масштаба среднего предприятия считаю ее избыточной слегка

0

Сообщение от krapotkin если очень хочется все-таки сделать ORM, прочитайте документацию например на TMS aurelis или любую другую реализацию ORM имхо штука очень спорная для задач масштаба среднего предприятия считаю ее избыточной слегка

Благодарю за совет, посмотрю что это и разберусь, раз советуете ) но с мои примером уже разобрался, пока что оставлю так, а ORM посмотрю почитаю может переделаю что бы работало по другому )

Добавлено через 21 минуту
Как то рылся по google и сплошные примеры БД мол типа есть одна таблица и один класс, а что бы найти со связками и как тогда делать фиг нароешь... куда не плюнь примеры в одну таблицу... (

0

да
вся сложность взаимодействия таких систем в их связях

если мы говорим про мобильные приложения - каждый класс должен уметь себя передавать/восстанавливать
а потом уже процедура, которая ведает связанными классами
а еще отдельно - работа с классами - справочниками...
в "универсальной" системе сложно все предусмотреть
на эту тему можно целую статью написать, тут не влезет ((

0

Ну статью писать не стоит Просто дело в том что у меня есть манагеры для каждого класса то есть да бы он умел себя записать вычитать и тд. В пом числе и создать для себя таблицу ну это все впринципе ясно ) есть общий манагер который наследуется от SQLiteOpenHelper и потом вызывает метод каждого Манагера что бы тот создал нужную таблицу, в принципе с моей точки зрения это логично... НО БЛИН: а как же тогда быть с тоблицами соответствий (id,id) их тогда кто должен создавать, у них получается есть 2-ва форен кея и получается что весь мусор от с названиями таблиц и тд нужно хранить и в основном Манагере, а если я храню и там и там как скрытые данные то какой тогда смысл в создании таблиц в отдельных Манагерах, вот путаница страшная и что с этим делать фиг пойму

Добавлено через 1 минуту
Сейчас склоняюсь к мысли что нужно плюнуть на все это, пусть МЕЙН МАНАГЕР создает всю базу и сам контролирует этот вопрос, а манагеры будут уже работать только с сылкой на базу и данными которые нужно вычитать/записать/удалить/обновить/и тд.

0

ИМХО название системы - намёк: им: , удобство и понятность не нужны.

0