| |
|
|
| | Доброго времени суток. Помогите чайнику. Есть две базы: 1 - Kod_ab, ysl1, ysl2, ysl3 и 2 - kod_ysl, name_ysl, cena. Как построить запрос, содержащий код абонента, а вместо кода услуг их стоимость?
SELECT kod_ab, cena AS y1
FROM spr_ab LEFT JOIN spr_ysl ON spr_ab.ysl1=spr_ysl.kod_ysl;
А дальше не знаю что делать. | |
| |
| |
| |
|
|
| | А дальше надо переделывать таблички.
1. Документы:
Код_документа
Код_абонента
...
2. УслугиПоДокументу
Код_документа
Код_Услуги
...
Только всё именовать по аглицки. | |
| |
| |
|
|
| |
|
|
| | Сейчас первая таблица неправильная. (да и вторая то же. Цены услуг постоянно меняются, нужна отдельная табличка для истории цен на услуги).
В ней 3 поля одинакового назначения - КодУслуги.
А услуг может быть оказано и 1 и 2 и 3. А что делать, если возникнет необходимость учесть 4 и более оказанные услуги?
Добавлять еще поля в таблицу? И так до предела?
Есть правильное решение: нормализовать таблички.
Простой вариант такого решения см. выше.
Там одна запись = одна услуга. А записей может быть от 1 до сколько оказано услуг. | |
| |
| |
|
|
| |
|
|
| | Имена сразу пишите правильно, например как здесь | |
| |
| |
| |
|
|
| | это приведена не совсем правильная (классическая) система именований
некоторые считают что таблицы сущностей должны именоваться в единственном числе - это поможет избавиться от коллизий при написании множественного-единственного числа на Английском (я готов согласиться, но уже не могу отказаться от привычки) <tblAddress; tblBooking> и т.п.
некоторые считают, что таблицы для связей многие-ко-многим должны именоваться от совокупности имен связанных таблиц (это конечно верно но иногда всречаются исключения) <tblFacilityOnApartment; tblStageOfBooking; tblVendor_By_Country> и т.п. но <tblServices> ИМХО исключение | |
| |
| |
| |
|
|
| | В данном примере абсолютно правильная схема именований, потому как близкая мне, и понятная. 
Если кто-то считает иначе - это его право.
Я в первую очередь имел ввиду исключение имен на кирилице и типа:
Kod_ab, ysl, kod_ysl, name_ysl, cena.
Десяток, другой слов перевести на аглицкий несложно и в процессе работы они запоминаются, что опять-таки полезно.
Плюс совсем другой "вид", когда смотришь структуру табличек или код. | |
| |
| |
| |
|
|
| |
Если кто-то считает иначе - это его право.
|
вообще в неиминге есть тонкости стиля, на которые следовало бы обратить внимание.
так создается логичная и <не заню как сказать> семантическая модель пространства имен объектов БД
мне кажется это важным - это некоторый язык БД являющийся важным описательным слоем который должен быть Содержательным, помимо абстрактного описания и дефиниции объектов он должен семантически описывать и взаимосвязи объектов между собой, и аспекты самих объектов БД и связь объектов модели (соответствие) объектам и субъектам учета и объектам и обстоятельсвам реального мира
вот в этой книге есть несколько интересных наблюдений по этому поводу с которыми я согласился и взял на вооружение
http://book.vsem.ru/binfo.asp?cod=105976&rp=6&up=1
(впрочем материала на эту тему довольно много - мне просто понравилось изложение)
вот статья http://www.citforum.ru/database/osbd/glava_24.shtml
семантическая модеь пространства имен БД не определяет степень подобия БД <как модели>реальному миру (в принципе можно именовать и "усл1; усл2; усл3", но существенно помогает понять степень подобия и ограничения модели. при разработке БД и /или ее рефакторинге это очень важно.
я с интересом читал Йожиковы креативы и с точки зрения нэйминга - как создается семантическая модель иного мира.
с уважением, Глокая Куздра | |
| |
| |
| |
|
|
| | в принципе можно именовать и "усл1; усл2; усл3"
С этим я уже согласиться не могу. (Лень постоянно переключать раскладку клавиатуры.)
А вот я еще не достиг того уровня просветления, что-бы влет читать Йожиковы креативы.
Постоянно торможу на непривычных буквосочетаниях. (Буквально читаю по буквам, как дошколенок) 
Статью почитаю.  | |
| |
| |
| |
|
|
| | Я только учусь программировать в Access, мне так понятнее называть поля и я абсолютно не понимаю принцип именования предложенного Lucas, возможно это придет со временем. Кстати база была переделана, убраны поля услуг и создана для них отдельная. Тот тапрос который нужен был получился. Огромное спасибо!!! Теперь не хватает мозгов посчитать для каждого абонента его стоимость услуг. Чтобы получилось примерно так:
kod_ab yslyga cena kod_ab oplata
1 31 50
1 32 60 = 1 180
1 33 70
2 31 50 = 2 50
3 = 3 0
Научите пожалуйста | |
| |
| |
