Форум » Для флейма » структура базы » Ответить

структура базы

Dima: Делал кто нибудь базу типа Область - район - населенный пункт ? Не могу решить как лучше. Все хранить в одной таблице или разных но тогда нужно будет делать привязки.......

Ответов - 36, стр: 1 2 All

SergKis: Dima Используй уникальные теги область область+район область+район+нас.пункт без unique и Scope для разрезов

Dima: SergKis Ты о том что все держать в одной таблице ? Эту инфу потом нужно привязать к контрагенту и если база "координат" будет жить в одной DBF тогда достаточно иметь лишь одно поле с кодом этой "координаты"

SergKis: Dima если полей в структуре немного, то можно в одном (есть ли назв. областей, районов, коды разные ?) если полей много (на область, р-он, нас. пункт) повторяющихся, то лучше сделать нормализацию базы (разложить в разные таблицы), связав их таблицей доп. (как в первом посте, без наим. и др. полей) и по ней связывать на отдельные табл.


Dima: Таблица вот такого плана примерно http://maps.vlasenko.net/ukraine/ua-list.csv или вот http://maps.vlasenko.net/belarus/by-list.csv Только первые 3 поля + еще улица добавится. PS Буду думать. Спасибо.

SergKis: Dima такой вариант в одном файле с тегами пойдет, добавить еще теги агент+область агент+область+район агент+область+район+нас.пункт без unique и комбинируешь от запросов, я уже говорил, что есть база с ~ 45 тегами

Dima: SergKis пишет: такой вариант в одном файле с тегами пойдет как бы да , но туда еще и улицу тулить нужно и тогда база распухнет ой.

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

Haz: Dima пишет: типа Область - район - населенный пункт ? Много подобного сделал , под SQL ориентировал, примерно такая структура Область - ID, NAME Район - ID, ID-Области, NAME Улица - ID, ID-Района, ID-Области, NAME Получается 3 справочника , есть избыточность в наследовании ID ( к примеру в улице , область можно на хранить, а получить от района ... но при этом очень страдает скорость поиска по условию улицы в конкретной области ) Это были справочники , в таблице данных держу только ID из этих справочников , в бровсе показываю через подмену блока выборки ЗЫ Первое поле в справочниках типа Autoinc . остальные INT и Char с такой структурой легко задается реляция или поиск по индексу

SergKis: Haz Диме надо добавить Агент - ID, NAME докуметы - ID, DATA, NOMER, агент ID, обл.ID, район ID, улица ID, ..., сумма1, ... может еще что то - это будет нормализованная база - это правильный вариант, но в первом посте Дима хотел как то иначе

Haz: SergKis пишет: это будет нормализованная база - это правильный вариант а по такой дорожке всегда иду , зато потом поиск и выборка в любой комбинации

SergKis: PS с базой OBLACTJ, RAION, ULICA, AGENT, DATA, NOMER, SUM1, SUM2, ... и тегами unique и нет - тоже не сложно, по тегам scope и выборки ( для простоты много раз отрыть базу с уст. на нужный тег) - можно даже сразу TsBrowse. Просто перекл. области\alias ...

Haz: SergKis пишет: для простоты Дима пишет под ADS , там есть такая штука как AOF - оптимизированнные фильтры. если по всем ID-шным полям есть индекс , то построение фильтра на сервере почти мгновенно. PS Я с этим ADS вообще обленился , забыл что такое SCOPE UNIQUE и прочее , а если пользовать SQL функционал , то не парюсь с изменением структур таблиц их склейкой для отчетов и пр.

SergKis: Haz пишет:есть такая штука как AOF - оптимизированнные фильтры В SixNsx они тоже были, жаль что сейчас нет. ADS финансово дорогая штука по лицензии, у нас только немцы приходили с ним и linuks-ом, но их прогнали шведы, норвеги, литовцы ...(хозяева) и теперь ни linuks-а ни ADS

Haz: SergKis пишет: ADS финансово дорогая штука по лицензии это еще дипломатично сказано уровень жадности там запредельный

ММК: Haz пишет: Это были справочники , в таблице данных держу только ID из этих справочников , в бровсе показываю через подмену блока выборки Делал так же . DBF,CUSTOM ADDITIVE, SCOPE...

Dima: Haz пишет: Получается 3 справочника , есть избыточность в наследовании ID Заказчик тоже так предлагает , но заполнять же их гимор будет :) Все увязки , привязки и тд и тп , понятно что изначально я его заполню по ссылке выше.... SergKis Даты , периоды это все не нужно. Есть условно говоря справочник контрагентов. Поля: "KOD_KL" ,"N" ,6,0 и "NAIM", "C",50,0 Нужно у каждого указать его координаты. Если база Область - Район и тд будет одна то достаточно добавить одно поле с кодом из этой базы. SergKis пишет: ADS финансово дорогая штука по лицензии Ну если "религия" позволяет , то этот вопрос решаем по крайней мере для десятой версии. Haz я не прав ?

PSP: Если понадобится отбор по области/району/городу/улице, то только отдельные справочники, имхо.

SergKis: Dima пишет:Ну если "религия" позволяет У нас теперь одна религия (ЕС) - плати за лицензию или штрафы (возможно с конфискацией рс) при комерческом использовании, что себе дороже Следит спец. команда с содействием государства - сильно не побалуешь. Думаю у вас после ассоциации в ту же сторону погонят (мы такое проходили)

Haz: Dima пишет: Ну если "религия" позволяет как говориться: "На каждую хитрую гайку ВСЕГДА найдется болт с левой резьбой" Так что вопрос риторический

Andrey: SergKis пишет: У нас теперь одна религия (ЕС) - плати за лицензию или штрафы (возможно с конфискацией рс) при комерческом использовании, Да уж... У нас любое предприятие копни, что частника, что муниципалку - всегда найдешь нелицензионное.... Что-то не слышно давно у нас про конфискацию компов... Кризис однако, не до разбора, что-где стоит...



полная версия страницы