Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Хитрая структура БД [D7, WinXP]

Страницы: 1 2 3 >
de. © (2008-01-28 14:30:00)
Здравствуйте уважаемые мастера!
Возник такой вопрос:

Структура БД абонентов была такова:

tPoint – Населенный пункт IdPoint -Ключь Point tStreet- Улицы IdStreet -Ключь IdPoint Street tAbonent- Абоненты Ls Fam Nam Otch Nd NdDr Nk NkDr DatS DatP

Необходимо переделать структуру БД под такову:
tPoint – Населенный пункт IdPoint -Ключь Point tStreet- Улицы IdStreet -Ключь IdPoint Street tHome- Дома IdHome -Ключь Nd NdDr NdLit tEntrance- Подъезды IdEntrance -Ключь Np NpDr NpLit tApartment- Квартиры IdApartment -Ключь Nk NkDr NkLit tRoom- Комнаты IdRoom -Ключь Ls tAbonent- Абоненты Ls Fam Nam Otch DatS DatP

Всебы нечего, но структура сложна при добавлении нового абонента.

Если в первой структуре при добавлении нового абонента мы обходились редактированием только одной таблицы tAbonent, то в новой необходимо:
-добавить абонента в tAbonent
-добавить новый дом в tHome (или выбрать существующий)
-далее подъезд
-квартиру
-комнату

В приложении клиенте этой БД
-В первом случае у меня были компоненты грубо говоря завязаны на одной таблице tAbonent, и я мог спокойно добавлять редактировать и т.д.
-Но во втором случае просматривать абонента могу т.е. вводим ЛС (Лицевой счет) открывается НД tAbonent, далее по ЛС связуюсь с tRoom возвращая тем самым IdApartment, потом по IdApartment возвращаю IdEntrance и т.д. раскручиваю до tPoint.

Но вот редактировать такую структуру как? Как завязать НД и компоненты чтобы добавлять нового абонента не могу представить….

Может кто сталкивался с такой структурой?

carmen987 (2008-02-06 18:06:00) [1]
лично я решил эту проблему следующим образом:
в карточке абонента записую следующие данные - номер счета, участок, ФИО, улица, дом, квартира. А потом в раздели точки учета добавляю счетчики которые висят на это абоненте, и все расчеты ведутся по точкам учета. а точек учета (можна понимать счетчиков) может сколько хочеш, и стоять они могут на разных улицах или местах

de. (2008-01-29 15:43:00) [2]

> Sergey13 © (29.01.08 15:37) [39]

Ок. Спас. Вопрос снят.

de. (2008-01-29 15:42:00) [3]

> ANB © (29.01.08 15:33) [38]
> Да. ГК РФ тоже не помешает. Я вот не въезжаю, на каком основании,
> если что, электросеть будет с меня долги взыскивать ? Они
> даже не знают с кого :)

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

Sergey13 (2008-01-29 15:37:00) [4]
> [36] de. (29.01.08 15:21)
> Какая литература может помочь в данном вопросе. ?

Данный конкретный случай в литературе вряд ли описан. Так что придется читать нечто более абстрактное. Ищи по "проектирование БД". На sql.ru много литературы вроде было.

ANB (2008-01-29 15:33:00) [5]
Да. ГК РФ тоже не помешает. Я вот не въезжаю, на каком основании, если что, электросеть будет с меня долги взыскивать ? Они даже не знают с кого :)

ANB (2008-01-29 15:32:00) [6]

> Какая литература может помочь в данном вопросе. ?

ПБУ, Методички по учету в твоей конторе. И книжки по теории построения БД.

de. (2008-01-29 15:21:00) [7]

> Sergey13 © (29.01.08 14:37) [34]

Какая литература может помочь в данном вопросе. ?

de. (2008-01-29 15:08:00) [8]

> Игорь Шевченко © (29.01.08 14:37) [33]

Давайте разведем дискуссию о орфографии, и Широте Русской речи. :-)

Sergey13 (2008-01-29 14:37:00) [9]
> [31] de. (29.01.08 14:30)
> А если и вправду сказать то не смешно... :'-|

Зато, ИМХО, это самая интересная часть по написанию приложения для БД.

Игорь Шевченко (2008-01-29 14:37:00) [10]

> В эдиале

Это где ?

Sergey13 (2008-01-29 14:36:00) [11]
> [31] de. (29.01.08 14:30)
> Что понимается под видом счетчика.?

> [29] de. (29.01.08 14:02)
> А счетчик этот горажный, или общедомовой

de. (2008-01-29 14:30:00) [12]

> Теперь надо еще больше думать КАК эту структуру сделать.

:-))))))))))))))) А если и вправду сказать то не смешно... :'-|

> Ну вот например таблицы Подъеды и Комнаты я бы выкинул нафиг.

Угу.

> LS - это ведь лицевой счет?

Угу.

> Зато добавил бы возможно справочник видов счетчиков.

Что понимается под видом счетчика.?

Sergey13 (2008-01-29 14:24:00) [13]
> [29] de. (29.01.08 14:02)
> Все оче долго думали и пришли к выводу переделать структуру....
Теперь надо еще больше думать КАК эту структуру сделать.

> еще + каждая таблица tHome, tEntrance, и т.д. несет всебе кучу полей....
Ну вот например таблицы Подъеды и Комнаты я бы выкинул нафиг. Если в одной квартире будет несколько счетов (LS - это ведь лицевой счет?) не будет ничего страшного. И не важно какой там санузел - совмещенный или раздельный.
Зато добавил бы возможно справочник видов счетчиков.

> А дома привязаны к участкам.....
И видимо справочник участков. И сделал ссылку из абонентов на эти участки, раз уж фактически счетчик может стоять не по указанному адресу.

de. (2008-01-29 14:02:00) [14]

> ANB © (29.01.08 13:12) [28]

Спору нет! Фактически интересен сам счетчик как точка сбыта, а абонент всеголиш лицо которое "транспортирует показания" к оператору который их учтет...

Данная схема реализована в Гос секторе, но в Быте всезавязанно именно на адресе абонента т.е. скажем Г.ПТФУСЮКИНО, УЛ.ЛЕНИНА, Д.5, К10, П/О №3 ИВАНОВ ИВАН ИВАНОВИЧ СЧЕТЧИК №536473873. А счетчик этот горажный, или общедомовой, бордак в старой базе проявляется тогда когда начинают просить такие отсчеты например как "Сколько кВт*ч пришлось на душу населения на 8 участке" а гораж абонента расположен рядом в томже районе но на участке 9, А дома привязаны к участкам.....

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

Все оче долго думали и пришли к выводу переделать структуру....

еще + каждая таблица tHome, tEntrance, и т.д. несет всебе кучу полей....
Объединить все в одну таблицу, это подписать приговор оператору!

Вот поэтому была выбрана иерархия.

ANB (2008-01-29 13:12:00) [15]

> из неё добавляем или выбираем улицы подъезды

А зачем откатывать уже добавленную улицу, если передумали сохранять клиента ?
И зачем вообще стартовать транзакцию, если еще не известно, а будет ли вообще модификация данных ?

> DiamondShark © (28.01.08 19:39) [25]

+1. Один геморрой с этими обертками над таблицами.

> Начнём с того, что у абонента нет счётчика.
> Счётчик Установлен в Месте, а Абонент Прописан по Месту
> жительства.
> У счётчика есть Тип, а абонент за счётчик Отвечает.

-1. :)
Например, в энергосбыте мой счетчик записан на абонента, который проживал по этому адресу лет 10 назад минимум. :)
Посему, идея привязать счетчик к адресу более правильная.

Johnmen (2008-01-28 20:55:00) [16]

> Interior (28.01.08 20:33) [26]

Именно так работают с тр-ми недоучившиеся студенты...

Interior (2008-01-28 20:33:00) [17]
Транзакции еще никто не отменял.
При добавлении абонента начинаем транзакцию
появляем форму добавления абонента
из неё добавляем или выбираем улицы подъезды
если абонент добавляется, то Commit все добавлениям,
если нет, то извиняйте.
В целом проблем не видно.

DiamondShark (2008-01-28 19:39:00) [18]

> Потому и придумали OR слой.

А нафига способствовать глобальному потеплению?

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

А перегонка данных между изоморфными моелями -- это только лишние джоули.

Kolan (2008-01-28 19:25:00) [19]
> Иерархические структуры чужды реляционной модели так же,
> как зонтик рыбе.

Потому и придумали OR слой.

Johnmen (2008-01-28 19:21:00) [20]

> Kolan © (28.01.08 18:25) [20]
> Настоятельно рекомендую вместо записей использовать иерерхию классов.

Иерархические структуры чужды реляционной модели так же, как зонтик рыбе.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »