Приемы работы с БД, поделитесь опытом.

← →
Kolan © (2006-10-25 10:00) [0]

Здравствуйте,
Хочу побыстрее пройти начальный этап обучения работы с БД. :)
Представьте, что есть база(MSDE) из 1 таблицы - "Пользователи" и мне надо уметь "Добавить", "Удалить", "Редактировать" пользователя. Как это можно сделать:

1. Кинуть на форму ADOQuery, DataSourse, DBGRid, DBNavigator. Настроить и работать..

2. Кинуть тоже самое, но без Навигатора. Написть 3 запроса на SQL и подставлять их в ADOQuery.

3. То к чему я склоняюсь, но нехочу наделать кучу ошибок.
Сделать класс "доступа к БД". В нем же создать все компоненты работы с БД. Сделать функции типа:
"Добавить пользоватея", "Вывести пользователей(TDBGRid)" ну и тд.

Как делаете это вы?

← →
Sergey13 © (2006-10-25 10:18) [1]

ИМХО, все зависит от масштабов создаваемой системы.
Наличие на форме нафинатора никак не соотносится с наличием или отсутствием класса.

← →
Kolan © (2006-10-25 10:35) [2]

> ИМХО, все зависит от масштабов создаваемой системы.

Средние масштабы.

Дело в том, что это моя первая работа с БД. И я нехочу ошибко наделать... :)

← →
ANB © (2006-10-25 10:36) [3]

>
> Средние масштабы.
>
> Дело в том, что это моя первая работа с БД.

Хреново стыкуется. Начни с оооочень маленьких масштабов. Иначе запорешь проект.

← →
Kolan © (2006-10-25 10:50) [4]

> [3] ANB © (25.10.06 10:36)
>
> >
> > Средние масштабы.
> >
> > Дело в том, что это моя первая работа с БД.
>
> Хреново стыкуется. Начни с оооочень маленьких масштабов.
> Иначе запорешь проект.

Пусть так, все в моих руках. Надо будет переделаю..

← →
ANB © (2006-10-25 10:51) [5]

> Надо будет переделаю..

Сначала напиши то, что потом переделывать будешь :)

← →
Sergey13 © (2006-10-25 10:52) [6]

> Средние масштабы.

Кому и кобыла невеста. (с) 12 стульев

Я к тому, что понятие "средний масштаб" очень у всех разное.
Если подзадача "доступ в БД" входит в несколько подсистем одной системы, и тем более, если она входит в несколько систем практически без изменения, то наверное целесообразно сделать класс. Если это разовая задачка в первой разрабатываемой системе - заморачиваться на это не имеет смысла, ИМХО.

← →
Kolan © (2006-10-25 10:56) [7]

> Я к тому, что понятие "средний масштаб" очень у всех разное.

Ну таблиц всего 6-7, но задачи серьёзные надо решать. Анализ там итд.. Выборки сложные.

> Если это разовая задачка в первой разрабатываемой системе
> - заморачиваться на это не имеет смысла, ИМХО.

Как бы первая и не разовая. И делать хочется качественно..

Ну расскажите как вы делаете, а.. :)

← →
Sergey13 © (2006-10-25 11:07) [8]

> [7] Kolan © (25.10.06 10:56)

MSDE - а там что, нет встроенного механизма регламентации доступа? Сомневаюсь я что-то в этом. Скорее всего есть, и желательно хорошенько разобраться в нем, чтобы не изобретать велосипед.
Сложные выборки с анализом по 6-7 таблицам, как и наличие ДБНафигатора на форме, не имеют никакого отношения к наличию класса "доступа к БД".

Я не пишу подобные классы и полагаюсь на систему аутентификации серверов БД - мне этого хватает.

← →
dr Gonzo © (2006-10-25 11:29) [9]

Я пользуюсь правилом БД контролы только для ПРОСМОТРА даннык.

Все изменения только через классы. Т.е. по логике должен быть класс :

TUser = Class (TXXXXX) public function Load():...; function Save():...; function Delete():...; end;

Из такиех классов легко сформировать как раз движок о чем, собственно пункт 3.

← →
Anatoly Podgoretsky © (2006-10-25 12:10) [10]

> 2. Кинуть тоже самое, но без Навигатора. Написть

Если сделаешь сразу без нафигатора, то идешь правильным путем.
И последний шаг - выкинуть ADOQuery и заменить его на AdoDataset.
И наиболее серьезная ошибка, а где AdoConnection?

← →
ANB © (2006-10-25 12:10) [11]

> Все изменения только через классы.

Все изменения - только через хранимки. Гранты только на селекты выполнение хранимок. В хранимках уточнять права конкретного пользователя на изменение именно этой строчки.

← →
Anatoly Podgoretsky © (2006-10-25 12:14) [12]

> MSDE - а там что, нет встроенного механизма регламентации
> доступа?

Есть, это же полноценный MS SQL Server, на который наложены искуственные ограничения, маркетингового характера.

← →
Sergey13 © (2006-10-25 13:05) [13]

> [12] Anatoly Podgoretsky © (25.10.06 12:14)

Потому я и сомневался, и как видно не зря.

Сомнения его не обманули. (с) мультфильм

> И последний шаг - выкинуть ADOQuery и заменить его на AdoDataset.
> И наиболее серьезная ошибка, а где AdoConnection?

Понятно, надо с ADO еще поразбираться. Благодарю за совет.

> Все изменения - только через хранимки. Гранты только на
> селекты выполнение хранимок. В хранимках уточнять права
> конкретного пользователя на изменение именно этой строчки.

Пока ниасилю :) Но буду иметь в виду..

> [8] Sergey13 © (25.10.06 11:07)

Пользователь в Базе не для разграничения доступа к базе, а для сохранения кто работал, когда итд..

> dr Gonzo © (25.10.06 11:29)

Вот вот я об этом и думал.. Наверно так и сделаю..

Всех благодарю..

> И последний шаг - выкинуть ADOQuery и заменить его на AdoDataset.
> И наиболее серьезная ошибка, а где AdoConnection?

Done.

dr Gonzo © (25.10.06 11:29)
А компоненты доступа к БД ты в класс(например в общий придок) инкапсулируешь?

Решил так:
Сделаю менеджер базы, там будуут все компоненты для связи и выполнения запросов.
Сделаю по менеджеру для каждой таблицы(даже наверно сущности, те менеждер и с несколькими таблицами работать может). А комммады будут типа таких:
function AddNewOperator(SurName, Name, PatronymicName: string; BaseManager: TBaseManager): boolean;
Те для выполнения команды нужен менеджер базы.

Все мелкие менеджеры потом объединю с пом. еще одного менеджера...

Ну как?

А компоненты доступа к БД ты в класс(например в общий придок) инкапсулируешь?

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

Еще советую сделать класс, который будет сразу отдавать настроенный и готовый к работе компонент доступа к данным (ADOStoredProcedure, ADOQuery, ADOCommand). Паттерн даж вроде есть на этот счёт :)

При проектировании БД надо итти не от "компонент", "серверов", "таблиц" и т.д., а от "сущностей". Т.е. от того, ЧТО должна описывать информация, хранимая в БД. Начать надо с описания этих сущностей НА БУМАГЕ, попытаться нарисовать связи между ними (зависимости), выделить общие характеристики и способы поведения "в жизни", выяснить в подробностях вид, состав и характер входной информации и ожидаемых результатов. Иными словами - построить модель объекта автоматизации. И только потом заморачиваться на тему, писать ли библиотку классов или использовать "быструю", но менее унифицированную технологию программирования.

← →
Petr V.Abramov (2006-10-27 01:17) [19]

Приемы работы с БД, поделитесь опытом. Найти похожие ветки