1

Тема: Проектування бази даних: проблема міст і районів

Доброго дня. Проектую базу даних для сайту, і виникла проблемка:
Є таблиця з працівниками, і треба зробити, щоб були відомості про місто і район працівника. Але! Може бути район міста (наприклад Львів, Галицький район), а може бути місто у районі (Наприклад, Пустомити Пустомитівського району). Відповідно, потрібно забезпечити якийсь зв"язок між районами і містами. Сам я тільки зараз почав вникати в серйозне проектування БД, і чую п"ятою точкою, що тут має бути зв"язок many to many, але не можу чітко зрозуміти, що куди і як має відноситись.
Дякую

2 Востаннє редагувалося Blast (03.08.2014 00:17:24)

Re: Проектування бази даних: проблема міст і районів

дел

Подякували: koala, Torbins3

3

Re: Проектування бази даних: проблема міст і районів

Matvik написав:

Доброго дня. Проектую базу даних для сайту, і виникла проблемка:
Є таблиця з працівниками, і треба зробити, щоб були відомості про місто і район працівника. Але! Може бути район міста (наприклад Львів, Галицький район), а може бути місто у районі (Наприклад, Пустомити Пустомитівського району). Відповідно, потрібно забезпечити якийсь зв"язок між районами і містами. Сам я тільки зараз почав вникати в серйозне проектування БД, і чую п"ятою точкою, що тут має бути зв"язок many to many, але не можу чітко зрозуміти, що куди і як має відноситись.
Дякую

Це абсолютно різні райони по своїй суті. Ні в якому разі не пишіть їх в одне поле. В іншому разі при застосуванні вашої бази до, наприклад, Вінниці, ви гарантовано отримаєте проблему, намагаючись занести особу, що проживає у Вінницькому районі, місті Вінниця, Ленінському районі.

Подякували: Torbins1

4

Re: Проектування бази даних: проблема міст і районів

Panda написав:
Прихований текст

3-и колонки навіть 5ть
1.Область
2.район
3.місто
4.Район міста
5.Адреса

А в чому власне проблема ?

Ок, так доволі непогано було б. Я навіть скоріше зроблю так: перший рівень (області та КИїв, бо він до області прирівнюється), другий (міста обласного підпорядкування, напр. Львів і райнои області, і третій (населений пункт району, або район міста). Тоді буде чітко, і по-порядку.
Але в мене ще таке запитання: яким чином на рівня зв'язків в базі можна зробити так при такій структурі, щоб при виборі Львова з випадаючого списку, в наступному полі можна було вибрати не всі райони, а лише ті, які є у Львові. Тобто зрозуміло, що можна на рівні запитів фільтрувати, але хотілось би гарніше якось

5

Re: Проектування бази даних: проблема міст і районів

Matvik написав:

Ок, так доволі непогано було б. Я навіть скоріше зроблю так: перший рівень (області та КИїв, бо він до області прирівнюється), другий (міста обласного підпорядкування, напр. Львів і райнои області, і третій (населений пункт району, або район міста). Тоді буде чітко, і по-порядку.

А що буде, коли раптом виявиться, що десь в Україні є районне місто, поділене на райони?
Другу проблему ви уже самі знайшли:

Matvik написав:

Але в мене ще таке запитання: яким чином на рівня зв'язків в базі можна зробити так при такій структурі, щоб при виборі Львова з випадаючого списку, в наступному полі можна було вибрати не всі райони, а лише ті, які є у Львові. Тобто зрозуміло, що можна на рівні запитів фільтрувати, але хотілось би гарніше якось

Тому не економте на сірниках. Оптимізації завжди проводять за результатами тестування, коли програма уже повністю готова.
Зробіть більше полів і не морочте собі голову.

Подякували: quez1

6

Re: Проектування бази даних: проблема міст і районів

А що буде, коли раптом виявиться, що десь в Україні є районне місто, поділене на райони? -
Ну власне там не буде обов'язково аж так докладно описувати, тобто якщо місто районне, то вже його район не буде потрібний.
Зробив таку схему (те, про що мова, справа внизу):
http://s18.postimg.org/8q7420am1/DBChema.png
Адекватно?

7

Re: Проектування бази даних: проблема міст і районів

якщо місто районне, то вже його район не буде потрібний.

Я не був би таким впевненим

До речі, нащо виносити адресу в окремі таблиці? Як на мене, краще писати її прямо у worker.

Подякували: Torbins1

8

Re: Проектування бази даних: проблема міст і районів

Так, я також про Кривий ріг подумав. Ну, але поки так.
Навіщо окремо? Ну так щоб можна було наприклад при додаванні нового працівника був спершу випадаючий список областей, після вибору області генерувався випадаючий список районів тільки цієї області, і так далі.
Яким чином це реалізувати, якщо записувати просто і область. і район, і місто в одному полі в таблиці працівників?

9

Re: Проектування бази даних: проблема міст і районів

Ну я все ж не став би робити настільки радикально і зробив би для кожного рівня адреси по полю — країна, область, район, і т. д. Чи можна представити таку штуку у вигляді випадаючого списку, не маю анінайменшого поняття. Але якщо у вас є аргументи за виніс адреси, то варто так і залишити.

Подякували: Torbins1

10 Востаннє редагувалося Torbins (01.06.2014 21:59:23)

Re: Проектування бази даних: проблема міст і районів

Matvik написав:

Яким чином це реалізувати, якщо записувати просто і область. і район, і місто в одному полі в таблиці працівників?

Для них усіх повинні бути окремі поля, тоді можна буде написати SQL з GROUP BY. Думаю, через конструктор запитів його також можна побудувати. Має бути щось типу:

SELECT 
  NasPunkt
FROM 
  oxm_addresses
WHERE 
  Raion = "Криворізький" 
GROUP BY 
  NasPunkt

Можна винести це все в окрему таблицю з адресами.

11 Востаннє редагувалося Matvik (01.06.2014 22:48:33)

Re: Проектування бази даних: проблема міст і районів

Ну але тоді там багато повторів виходить, в цій новій таблиці. Тобто чисто з точки зору оптимізації об'єму краще щоб було три таблички з додатковим стовпцем ідентифікатора батьківської області, чи району, чи міста в кожній, аніж одна, де ці назви просто повторяються багато разів в різних стовпцях.

Не забувайте. що я перший раз всерйоз проектую БД,  і начитався всяких нормальних форм. і рекомендацій) НАскільки я розумію, пропагується саме такий підхід

12

Re: Проектування бази даних: проблема міст і районів

Matvik
Я вашу задачу бачу наступним чином:

схема

http://osidok.pp.ua/images/2014/06/03/db.png