Сообщений в теме: 10

[ceasar]

Есть такое задание в Казахстане есть 14 областей. В каждой области в среднем по 10 районов, в каждом районе по 15 населенных пунктов, в каждой из них есть школы. Также должен стоять признак наличия город это село.

Таблица Первая:
Назовем ее Area (Область)

1) ID_Area int (autoincrement) тип int
2) Name_Area (название области) тип nvarchar
3) Description_Area (описание области) тип nvarchar

Таблица Вторая
Назовем ее Region
1) ID_Region
2)Name_Region
3)Description_Region

Таблица третья School
1) ID_School
2) Name_School
4) Adress
5) Phone
6) Library (есть или нет наличие)
7) Contact_Name

В идеале программа выглядит так создается прога забиваются данные. К примеру нужно отобразить школы всей области то в DataGrid должно отобразиться школы принадлежащий к определенной области к примеру Костанайской. Или же нужно отобразить школы определенного района точно также должен быть как указано выше.

Посоветуйте пож-та что надо добавить или исключить и каким образом связть таблицы имеются ввиду через внешние ключи я их в таблицах не написал исходя из того что может Вы подскажете наилучший вариант. Просто это программа в будущем будет использоваться по 5-6 странам СНГ и записей может быть несколько миллионов.

[T. Anre]

Есть такое задание в Казахстане есть 14 областей. В каждой области в среднем по 10 районов, в каждом районе по 15 населенных пунктов, в каждой из них есть школы. Также должен стоять признак наличия город это село.

Таблица Первая:
Назовем ее Area (Область)

1) ID_Area int (autoincrement) тип int
2) Name_Area (название области) тип nvarchar
3) Description_Area (описание области) тип nvarchar

Таблица Вторая
Назовем ее Region
1) ID_Region
2)Name_Region
3)Description_Region

Таблица третья School
1) ID_School
2) Name_School
4) Adress
5) Phone
6) Library (есть или нет наличие)
7) Contact_Name

В идеале программа выглядит так создается прога забиваются данные. К примеру нужно отобразить школы всей области то в DataGrid должно отобразиться школы принадлежащий к определенной области к примеру Костанайской. Или же нужно отобразить школы определенного района точно также должен быть как указано выше.

Посоветуйте пож-та что надо добавить или исключить и каким образом связть таблицы имеются ввиду через внешние ключи я их в таблицах не написал исходя из того что может Вы подскажете наилучший вариант. Просто это программа в будущем будет использоваться по 5-6 странам СНГ и записей может быть несколько миллионов.

Действуйте по принципу от листьев к стволу - это самый простой вариант. Если данных будет "ой как много", то в этом случае вынесите деревья в отдельную таблицу. Судя по тому что первая и вторая таблица идентичны, то предлагаю их объединить, распознавать area по parent_id=0, остальное рассматривать как region.

[|imp|]

Как уже и предлагалось, объедини две таблицы (Область и Регион), в таблицы (Const) заведи записи:

1 ? Область;
2 ? Регион;

В поле ID_Sign указывай 1 или 2 в зависимости регион это или область
При записи региона в ID_parent указывай ID-области.

В таблицы (Школы) в ID_Parent указывай ID-региона.
Так Library_School записываем 0 ? нет 1 ? есть (библиотеки).
Также в константах можно добавить значение (Город, село, поселок) и произвести связь с другим полем.

Можно обойтись и без таблицы (Const) делать проверку по ID_parent если 0- то область, если есть значение то регион.

[ceasar]

спасибо за помощь, если бдут изменения закину сюда же

[vadim]

Есть такое задание в Казахстане есть 14 областей. В каждой области в среднем по 10 районов, в каждом районе по 15 населенных пунктов, в каждой из них есть школы. Также должен стоять признак наличия город это село.

Таблица Первая:
Назовем ее Area (Область)

1) ID_Area int (autoincrement) тип int
2) Name_Area (название области) тип nvarchar
3) Description_Area (описание области) тип nvarchar

Таблица Вторая
Назовем ее Region
1) ID_Region
2)Name_Region
3)Description_Region

Таблица третья School
1) ID_School
2) Name_School
4) Adress
5) Phone
6) Library (есть или нет наличие)
7) Contact_Name

В идеале программа выглядит так создается прога забиваются данные. К примеру нужно отобразить школы всей области то в DataGrid должно отобразиться школы принадлежащий к определенной области к примеру Костанайской. Или же нужно отобразить школы определенного района точно также должен быть как указано выше.

Посоветуйте пож-та что надо добавить или исключить и каким образом связть таблицы имеются ввиду через внешние ключи я их в таблицах не написал исходя из того что может Вы подскажете наилучший вариант. Просто это программа в будущем будет использоваться по 5-6 странам СНГ и записей может быть несколько миллионов.

1. ceasar, ты сам написал 4 сущности (область, район, населенный пункт, школа), а таблицы сделал только для 3-х... для начала добавь таблицу для населенных пунктов
2. дальше все будет зависеть от:
а) объема данных;
б)режима использования.
Если бы это был справочник на сотню-тысячу записей, для того, чтобы человек ткнул пальцем в окошечке и посмотрел результат - все вообще можно было бы запихнуть в одну таблицу. При нынешней производительности компов даже старый PC справится с этой задачей за секунду. А быстрее человеку и не надо. Но раз у вас планируется так много - то сначала продумай все варианты, с которыми будут обращаться к данным. Например, "все школы города", "все школы района", "где находится такая-то школа"... То, что будет являться ключевым для выбора, должно быть обязательно проиндексировано. И от него долна быть наиболее простая и короткая связь к тому, что нужно вытащить (школы). Объединять сущности в одну таблицу не торопись. Это только осложнит поиск по нескольким критериям одновременно...
3. По-моему, идеальным для системы поиска был бы вариант, где есть три справочника (область, район, населенный пункт), в каждом из которых есть свой ID, и есть список школ, в котором есть все эти три ID как ссылки, плюс есть свой ID. Вероятнее всего, должны быть дополнительные индексы по наименованиям всех трех сущностей плюс по номеру школы (люди, как правило, все ищут по названию или номеру). Вот и все премудрости...

Сообщение отредактировал vadim: 09.10.2006, 11:19:40

[Visual1]

Я бы придерживался строгой иерархии, чтобы все таблицы были связаны отношением "один к многим". Связь - только через главные уникальные ключи типа integer, как здесь и предлагают.
У каждой области есть несколько районов, у каждого района - несколько школ. С объединением таблиц районов и областей в одну таблицу я не согласен - по-моему, увеличивается избыточность, и каждая запись о районе будет содержать поле области. Область - по любому вышестоящий объект иерархии, выше нее только страна. Кстати, поскольку автор заявляет об использовании программы в 5-6 странах СНГ, то таблицу Countries делать сам бог (или Кодт) велел. Вообще, настоятельно рекомендую внимательно изучить (а кто уже знает - освежить свои познания) требования к нормализации реляционных таблиц, все насчет приведения к первой, второй и третьей нормальной форме.

И еще важно учесть, что в бывшем Советском Союзе любят переименовывать населенные пункты (НП). Казалось бы, не проблема - каждому НП можно присвоить уникальный числовой ID, вот и все дела. Но что будет, если потребуется сделать отчет за много лет? Будет довольно нелепо, если в отчете за период 1988 - 2008 гг. везде будет один и тот же город Астана (ведь в разные годы этот город имел разные названия). И еще, в каждой области в каждый период времени некоторые районы относились к этой области, затем они могли объединяться, разделяться и/или были переданы в соседнюю область. Да и сама область могла прекратить свое существование, а ее районы могли влиться в одну или несколько соседних областей.

По этим причинам я бы рекомендовал в каждой таблице вместе с полем Name (название района, города, области) иметь еще парочку полей типа Date. Например DateFrom - с какого времени, и DateTo - по какое время действует такое название. Или даже еще строже: для каждого уникального ID населенного пункта - отдельная табличка со всеми его названиями и датами, с какого по какое время эти названия действовали, а также с какого по какое время данный район/город находился в составе данной области. И те же самые правила для статуса НП: с какого времени по какое был районным, областным центром. Необходимо также полностью запретить пользователю вносить любые изменения в записи с названиями и датами прошлых лет.

[BAD]

Вижуал1 все написал. Вот только не понятна идея "Или даже еще строже: для каждого уникального ID населенного пункта - отдельная табличка со всеми его названиями и датами" - смысла нет. Зачем городить кучу таблиц, да еще и динамически?
Имха, во всех полях должно быть кк минимум 2 ключа - поле идентификатора и поле даты действия.
А дальше - по иерархии, с использованием связей.

[Visual1]

Вот только не понятна идея "Или даже еще строже: для каждого уникального ID населенного пункта - отдельная табличка со всеми его названиями и датами" - смысла нет. Зачем городить кучу таблиц, да еще и динамически?

Ну почему же "городить"? Что за слова такие? Я думаю, правильнее называть это разделением таблиц с целью максимального удаления из записей избыточной информации.

Каждый НП может иметь несколько названий, каждое из которых действовало на протяжении некоторого периода времени. Также на протяжении некоторого периода времени (необязательно того же, возможно другого) этот НП мог входить то в одну, то в другую область. А если этот НП - город на правах отдельной области (как Алматы или Астана)? Да еще у него есть подчиненные районы (Алмалинский, Бостандыкский, Медеуский и т.д.)? Здесь я не собираюсь преподавать нормализацию таблиц в реляционной БД (во многих книгах это превосходно изложено), скажу только, что связи типа "один к многим" вполне просматриваются, так что мое предложение не лишено смысла. Хотя вообще-то в теории реляционных БД нет жесткого требования максимальной нормализации, иногда ей сознательно жертвуют, ограничиваясь лишь 1-й, максимум 2-й нормальной формой. В любом случае, у каждого НП вполне может быть подчиненная таблица.

Есть проблема и потруднее: как автор собирается обеспечивать уникальность первичного ключа для каждого НП в пределах нескольких стран? Например, в каждой стране ведут свою базу данных, и каждый НП получает уникальный - конечно, в пределах своей страны - ID, который Auto Increment, по умолчанию начинается с 1, и в каждой новой записи возрастает на 1. Но уже на стадии проектирования таблиц надо подумать - а что, если данные каждой страны необходимо отправлять для обработки в какую-нибудь международную организацию? Тут есть над чем подумать: то ли постараться, чтобы в любой стране любой город Аксай, и любой поселок Аксу (такие названия есть по нескольку штук в Казахстане, но не только: есть и в России) имели уникальные ID не только в своей стране, но и в мире? Или (другой вариант) перейти к использованию составных ключей, уникальность которых достигается комбинацией ID страны, области и района?

[ceasar]

Всем привет еще раз!!! В данный момент моя задача сводится к тому что это будет только для Казахстана Visual1 правильно говорит как обеспечить уникальность в разных странах. В данном случае этого небудет будет тока в одной стране пока. В данном случае это не школы а кое что другое просто из-за коммерческой тайны я не могу раскрывать это, но в любом случае это эквивалентная аналогия ШКОЛА.

В данном случае составил 4 таблиы
Area (Область)
Region (регион)
Point (населенные пункты)
Main_Table (главная таблица котрую будут юзать больше всего)
но опять же терзают сомнения что так будет эффективно. записей уж слишком много будет порядка 500 000. Если никто не против я распишу опять в данном случае все таки коллективный разум бывает лучше чем потом из-за гордости сидеть и всю жизнь исправлять баги.

Закину картинку посомтрите пож-та как будет лучше сделать связи и в конце картинки сделаю комменты почему так сделал

Не знаю из-за чего, но нигде не увидел кнопочку добавить файл ну опубликовать . но выход нелучший но такой создал почту на www.ok.kz завел пользователя table_1986 пароль table посмотрите пож-та как лучше го реализовать

Сообщение отредактировал ceasar: 09.10.2006, 22:26:01

[ceasar]

кто может пож-та закиньте оттуда сюда картинку, что то не смог не нашел ничего такого чтобы закинуть. или ткните меня на эту кнопочку.

Но раз у вас планируется так много smile.gif - то сначала продумай все варианты, с которыми будут обращаться к данным. Например, "все школы города", "все школы района", "где находится такая-то школа"...

Вот именно это и надо никак немог правильно сформулировать. Как вот это сделать

Сообщение отредактировал ceasar: 09.10.2006, 22:30:42

[Vietnam]

2ceasar
Мне нужна информация по всем школам города Караганды!
Не поделишься ли, если у тебя есть такая инфа!
Или может кто жнает где можно найти такую информацию в электронном виде? может есть такой сайт специализированный??