Хитрая структура БД

← →
de. (2008-01-28 14:30) [0]

Здравствуйте уважаемые мастера!
Возник такой вопрос:

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

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.

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

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

← →
имя (2008-01-28 14:38) [1]

Удалено модератором

← →
de. (2008-01-28 14:41) [2]

> Z0LDBERGER (28.01.08 14:38) [1]

Незнаю один раз написал а потом просто копировал, ошибка... :-)

← →
Ega23 © (2008-01-28 14:48) [3]

детализация до подъезда и комнаты напрасна.
Достаточно номера дома и квартиры.

← →
de. (2008-01-28 14:56) [4]

> Ega23 © (28.01.08 14:48) [3]

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

Вопрос стал "рогом" именно в добавлении абонента и редактировании .

Кто чем сможет помочь ?

← →
de. (2008-01-28 15:00) [5]

> детализация до подъезда и комнаты напрасна.

В общих чертах объесню почему пришли к такой структуре.

Есть абонент у абонента есть счетчик.
Абонент может (его ЛС) может отвечать за
-личный счетчик
-общедомовой
-общеподъездный
-общеквартирный

понимаю что гиморой, но всеже..... вот так... и застрял...

← →
Ega23 © (2008-01-28 15:04) [6]

Начни с простого: опиши чё надо вообще.

← →
de. (2008-01-28 15:06) [7]

> Ega23 © (28.01.08 15:04) [6]

Ща.

← →
Kolan © (2008-01-28 15:08) [8]

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

Или развлекаться с UpdateObject  тут я кроме справки ниче не посоветую.

Или :
Для работы с 1 абонентом сделать форму с обычными контролами. Перед показом загружать в неё данные, после того, как нажали «ОК» получать введенные/измененные данные и делать сотв Insert/Update. Это, имхо, нормальный вариант в данном случае.

← →
de. (2008-01-28 15:15) [9]

Необходимо разработать форму абонента (Карточка абонента), которая бы редактировала такую структуру как я описал.

Вопрос наверное больше относится не к БД а к Delphi.

Надо в этой самой карточке создавать, редактировать абонента, т.е.

Вбили ФИО, вбили Улицу, дом, подъезд, квартиру, комнату, в комнате обозначили где расположен прибор учета (прихожая, кухня, и т.д.)

← →
de. (2008-01-28 15:20) [10]

> Kolan © (28.01.08 15:08) [8]

Вово вы меня поняли...!

Вот я об этом тоже думал... Тока вот реализовать не могу...

Думал создать чтото типа...

TDialogs = record Ls, Fam, Nam, Otch: String; DatS, DatP: TDateTime; IdStreet: Integer; Nd, NdDr, NdLit: String; Np, NpDr, NpLit: String; Nk, NkDr, NkLit: String; end;

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

← →
Sergey13 © (2008-01-28 15:21) [11]

> [9] de. (28.01.08 15:15)

Так а собственно в чем трудность то? Основное отличие (для заведения нового абонента) во втором варианте от первого в том, что ДО ВВОДА надо знать идентификатор справочника верхнего уровня. В остальном - обычная мастер-детальная связь, просто многоуровневая.
Что за СУБД?

← →
de. (2008-01-28 15:25) [12]

> Что за СУБД?

MS SQL 2000

← →
Sergey13 © (2008-01-28 15:45) [13]

> [12] de. (28.01.08 15:25)

Не знаю, можно ли в МССКЛ-е зарезервировать новое значение идентификатора заранее, но вроде можно вставляя новые значения в справочники в порядке иерархии, получать новые идентификаторы налету и применять эти результаты при вставке в подчиненные таблицы.

← →
de. (2008-01-28 15:55) [14]

И вправду все через Ж получается, структура идеально подходит под многоквартирные дома.!
Ну чтобы иметь связку ДОМ-АБОНЕНТ (если дом скажем частный) необходимо тянуть за собой пустые значения таблиц tEntrance, tApartment ... Вот ббб. связался...

← →
de. (2008-01-28 15:58) [15]

А есть ли примеры считывания значений из БД скажем

в

TDialogs = record
Ls, Fam, Nam, Otch: String;
DatS, DatP: TDateTime;
IdStreet: Integer;
Nd, NdDr, NdLit: String;
Np, NpDr, NpLit: String;
Nk, NkDr, NkLit: String;
end;

далее счетывания из этого типа

в

контролы

редактирование значений

и обратная запись

в

TDialogs = record
Ls, Fam, Nam, Otch: String;
DatS, DatP: TDateTime;
IdStreet: Integer;
Nd, NdDr, NdLit: String;
Np, NpDr, NpLit: String;
Nk, NkDr, NkLit: String;
end;

а далее уже из типа

в

БД

?

← →
Palladin © (2008-01-28 16:04) [16]

> [15] de. (28.01.08 15:58)

примеры? :) народ годы тратит на разработку систем
DB -> DBLayer -> DBObjects -> DBControls
а тут приходит чувак и просит примеры :)

← →
de. (2008-01-28 16:09) [17]

> Palladin © (28.01.08 16:04) [16]

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

← →
Sergey13 © (2008-01-28 16:47) [18]

> [17] de. (28.01.08 16:09)
> чтобы на грабли не наступить

Граблей бояться - в лес не ходить. 8-)

← →
Ega23 © (2008-01-28 17:00) [19]

А не надо получать. Объявляй ID как Identity, он сам чё надо вставит.

← →
Kolan © (2008-01-28 18:25) [20]

> TDialogs = record
> Ls, Fam, Nam, Otch: String;
> DatS, DatP: TDateTime;
> IdStreet: Integer;
> Nd, NdDr, NdLit: String;
> Np, NpDr, NpLit: String;
> Nk, NkDr, NkLit: String;
> end;

Оторвал бы за названия&#133 все бы оторвал&#133

Пример простой:

используете BDE как я понял&#133

function GetAbonent(AbonentID: Integer): TAbonent; Query := TQuery.Create(nil); try Query.SQL.Text := "SELECT * FROM tAbonent WHERE Ls = :AbonentID"; Query.ParamByName("AbonentID").AsInteger := AbonentID Query.Open; if not Query.Eof then bein Result.Fam := Query.FieldByName("Fam"); <итд&#133> end; finally Query.Close; Query.Free; end;

ЗЫ
Настоятельно рекомендую вместо записей использовать иерерхию классов.

← →
ANB © (2008-01-28 18:53) [21]

1. Добавить еще одну таблицу - Адреса, в полях которой собирать ссылки на справочники (все таблицы, кроме абонента). В принципе, можно прямо в абонента добавить все эти поля.
2. Реализовать возможность в эдите вызывать справочник, а справочник разрешить редактировать.
Кистате, все таблицы мона загнать в одну древовидную, вот только мс скл не умеет с ними работать, посему уж проще так оставить - количество уровней то фиксировано.
3. На форму редактирования / добавления абонента положить эдиты с кнопками. Можно положить один эдит с рассчитанной комплексной инфой об адресе и для редактирования адресов юзать отдельную форму (может пригодится в других местах).
4. Структуру адреса (кроме кв. и комнат) лучше подогнать под КЛАДР, тогда его мона будет импортить, а не вбивать руками.

> ЗЫ
> Настоятельно рекомендую вместо записей использовать иерерхию
> классов.

ЗЫ. Настоятельно рекомендую так не делать. Проблем меньше.

← →
DiamondShark © (2008-01-28 19:13) [22]

> В общих чертах объесню почему пришли к такой структуре.
>
> Есть абонент у абонента есть счетчик.
> Абонент может (его ЛС) может отвечать за
> -личный счетчик
> -общедомовой
> -общеподъездный
> -общеквартирный

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

Итого, вместо шизофренической структуры с рахитическими таблицами достаточно справочника Абонентов, справочника Счётчиков и таблицы-связки Абонент-Счётчик.

← →
Johnmen © (2008-01-28 19:21) [23]

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

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

← →
Kolan © (2008-01-28 19:25) [24]

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

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

← →
DiamondShark © (2008-01-28 19:39) [25]

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

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

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

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

← →
Interior (2008-01-28 20:33) [26]

Транзакции еще никто не отменял.
При добавлении абонента начинаем транзакцию
появляем форму добавления абонента
из неё добавляем или выбираем улицы подъезды
если абонент добавляется, то Commit все добавлениям,
если нет, то извиняйте.
В целом проблем не видно.

← →
Johnmen © (2008-01-28 20:55) [27]

> Interior (28.01.08 20:33) [26]

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

← →
ANB © (2008-01-29 13:12) [28]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← →
de. (2008-01-29 14:30) [31]

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

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

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

Угу.

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

Угу.

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

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

> [31] de. (29.01.08 14:30)
> Что понимается под видом счетчика.?

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

> В эдиале

Это где ?

> [31] de. (29.01.08 14:30)
> А если и вправду сказать то не смешно... :"-|

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

← →
de. (2008-01-29 15:08) [35]

← →
de. (2008-01-29 15:21) [36]

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

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

Да. ГК РФ тоже не помешает. Я вот не въезжаю, на каком основании, если что, электросеть будет с меня долги взыскивать ? Они даже не знают с кого :)

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

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

← →
de. (2008-01-29 15:42) [40]

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

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

Хитрая структура БД Найти похожие ветки