[БД] Как спроектировать таблицу "Клиенты"?
Ограничения на структуру, конечно же следует накладывать на стороне сервера, поэтому п3 не спортивный.
Создавать табличку с полами есть смысл только если их у тебя планируется несколько и список может расшириться (м, ж, детский, унисекс, не известен, не определен, ... - как при торговле одеждой, например). Поэтому если пола всего 2 - поставь ограничения в поле и не парься.
Создавать табличку с полами есть смысл только если их у тебя планируется несколько и список может расшириться (м, ж, детский, унисекс, не известен, не определен, ... - как при торговле одеждой, например). Поэтому если пола всего 2 - поставь ограничения в поле и не парься.
п2 минус Полы 
иногда в подобных случаях создается одна единственная справочная табла:
id, name, foreign_column_id,
т.е. пол, образование, соц. статус и т.д. кладутся в одну таблицу (уникальный идентификатор сквозной или в совокупности с foreign_column_id)
foreign_column_id - указывает на таблицу и поле (таблицы, поля) в которых могут использоваться эти значения - это ограничение можно жесткол прописать в constraint на поле, содержащее такую инфу по клиенту
//но на самом деле все твои справочные таблички сходны по структуре, поэтому каждой из них можно дать свой айдишник (таблицы справочника) и физически хранить в ОДНОЙ таблице
id, name, foreign_column_id,
т.е. пол, образование, соц. статус и т.д. кладутся в одну таблицу (уникальный идентификатор сквозной или в совокупности с foreign_column_id)
foreign_column_id - указывает на таблицу и поле (таблицы, поля) в которых могут использоваться эти значения - это ограничение можно жесткол прописать в constraint на поле, содержащее такую инфу по клиенту
//но на самом деле все твои справочные таблички сходны по структуре, поэтому каждой из них можно дать свой айдишник (таблицы справочника) и физически хранить в ОДНОЙ таблице
что такое нормальная форма знаешь?
так вот, таблички надо создавать согласно им.
http://www.unix.org.ua/osbd/glava_23.htm
http://www.google.com/search?hl=ru&q=%D0%BD%D0%BE%D1%80%...
так вот, таблички надо создавать согласно им.
http://www.unix.org.ua/osbd/glava_23.htm
http://www.google.com/search?hl=ru&q=%D0%BD%D0%BE%D1%80%...
п2 конечно.
Во-первых, пол - это bool. Только тогда он не пол, а "(Is)Male". Других полов кроме "женщина", "мужчина" и "затрудняюсь ответить"(null) у тебя не появится никогда. Ну я бы так, по крайней мере, сделал. Ну или через строку + ограничения в базе (и в проге тоже, естественно, там вообще дропдаун должон быть но бул мне более по нраву. Отдельная табличка для пола - это маразм, неудобный и тормозной причём.
Образование можно сделать отдельной табличкой, но предварительно потребовать от заказчика письменную расписку о том, что в процессе эксплуатации количество вариантов увеличится не более чем в два раза (ну, там, "бакалавр", "магистр", "неоконченное высшее", "кандидат физ-мат наук" а вставка поля "дополнительные пометки об образовании" оплачивается отдельно =) Или с самого начала понять, какие query они хотят запускать по образованию, и вынести всё остальное в отдельное текстовое поле без ограничений. А это - отдельной табличкой + дропдаун.
Все вышеперечисленное относится и к роду занятий.
Короче говоря: любые ограничения позволяют эффективно бороться с опечатками етс., как их не делай (хотя логику лучше в базе проверять где только можно но иногда нужна гибкость.
Образование можно сделать отдельной табличкой, но предварительно потребовать от заказчика письменную расписку о том, что в процессе эксплуатации количество вариантов увеличится не более чем в два раза (ну, там, "бакалавр", "магистр", "неоконченное высшее", "кандидат физ-мат наук" а вставка поля "дополнительные пометки об образовании" оплачивается отдельно =) Или с самого начала понять, какие query они хотят запускать по образованию, и вынести всё остальное в отдельное текстовое поле без ограничений. А это - отдельной табличкой + дропдаун.
Все вышеперечисленное относится и к роду занятий.
Короче говоря: любые ограничения позволяют эффективно бороться с опечатками етс., как их не делай (хотя логику лучше в базе проверять где только можно но иногда нужна гибкость.
Во-первых, пол - это bool. Только тогда он не пол, а "(Is)Male". Других полов кроме "женщина", "мужчина" и "затрудняюсь ответить"(null) у тебя не появится никогда."юридическое лицо"
Во-первых, пол - это bool. Только тогда он не пол, а "(Is)Male".Если база данных пойдёт на цивилизованный запад, то лучше сделать поле "(Is)Female".
Молодой человек, вы, кажется, ничего не понимаете в MS SQL Server. Используйте лучше Oracle.
Я бы посоветовал начать с любого приличного материала по нормализации данных. А после разборе с тем что это и для чего вопрос отпадет сам собой:)
Образование можно сделать отдельной табличкой, но предварительно потребовать от заказчика письменную расписку о том, что в процессе эксплуатации количество вариантов увеличится не более чем в два раза (ну, там, "бакалавр", "магистр", "неоконченное высшее", "кандидат физ-мат наук" а вставка поля "дополнительные пометки об образовании" оплачивается отдельно =) Или с самого начала понять, какие query они хотят запускать по образованию, и вынести всё остальное в отдельное текстовое поле без ограничений. А это - отдельной табличкой + дропдаун.
Все вышеперечисленное относится и к роду занятий.
проще все это сделать черз отдельную таблицу для решения связи типа многие ко многим. Ибо работает это довольно быстро при грамотной индексации. И снимает лишние проблемы с ограничением и расписками
Не могли бы вы посоветовать парочку любых приличных материалов по нормализации данных ?
Конноли, Берг. БД. Теория и практика (если не ошибаюсь, ибо дома). Там отлично расписано с прекрасными объяснениями и примерами, книга есть в продаже.
Если есть желание познакомиться с ней (я не в общаге живу) - пишите в личку, договоримся, я вам дам на неделю.
Но вообще - если и дальше заниматься БД - книгу стоит иметь, ибо классика и отличный матриал
Если есть желание познакомиться с ней (я не в общаге живу) - пишите в личку, договоримся, я вам дам на неделю.
Но вообще - если и дальше заниматься БД - книгу стоит иметь, ибо классика и отличный матриал
Спасибо за совет почитать классиков. Я согласен с тем, что чтение хороших субжевых книжек способствует прояснению сознания. Только имеется проблема во временем. К тому же я несколько раз изучал, что есть нормальные формы. Я подумаю над советом поботать еще.
Пожалуйста, объясни, где ты увидел в моем вопросе связь много ко многим?
Пожалуйста, объясни, где ты увидел в моем вопросе связь много ко многим?
Это был ответ прежнему респонденту (я в дереве смотрю форум).
А про вашу тему - в общем - проще через доменные ключи. То есть пол 0,1 , образование 0,1,2...
Потом если нет компонента позволяющего реализовывать домены (у меня есть такие, потому даже не парюсь) - то начитавыть значения другим способом.
Но во избежание путаницы лучше сделать все же внешние ключи к таблицам. Скорость это почти не уменьшит, зато от многих ошибок спасет. Я бы сделал так.
А про вашу тему - в общем - проще через доменные ключи. То есть пол 0,1 , образование 0,1,2...
Потом если нет компонента позволяющего реализовывать домены (у меня есть такие, потому даже не парюсь) - то начитавыть значения другим способом.
Но во избежание путаницы лучше сделать все же внешние ключи к таблицам. Скорость это почти не уменьшит, зато от многих ошибок спасет. Я бы сделал так.
Я вижу, кому вы отвечаете. В его решении я как раз и не вижу отношения много ко многим. А ваш окончательный совет совпадает с моим предложением 2.
Образование можно сделать отдельной табличкой, но предварительно потребовать от заказчика письменную расписку о том, что в процессе эксплуатации количество вариантов увеличится не более чем в два раза (ну, там, "бакалавр", "магистр", "неоконченное высшее", "кандидат физ-мат наук" а вставка поля "дополнительные пометки об образовании" оплачивается отдельно =) Или с самого начала понять, какие query они хотят запускать по образованию, и вынести всё остальное в отдельное текстовое поле без ограничений. А это - отдельной табличкой + дропдаун.
И здесь разве не так?
И да, второй ваш вариант сильно упростит реализацию клиентского приложения, в остальном же они примерно равнозначны.
+1 за п2.
проще все это сделать черз отдельную таблицу для решения связи типа многие ко многим. Ибо работает это довольно быстро при грамотной индексации. И снимает лишние проблемы с ограничением и распискамиЭто получается неоконченное дошкольное плюс кандитат физ.-мат. наук?
Оставить комментарий
Realist
Пусть имеется таблица "Клиенты". Про клиентов нужно знать пол, род занятий (пенсионер, служащий, бизнесмен, ... уровень образования (среднее, высшее, неполное высшее) ну и тому подобное.Запросы будут типа "сколько у нас человек с высшим образованием в клиентах?"
База MS SQL Server.
Как лучше поступить?
1) Создать одну табличку, соответствующие атрибуты сделать строками, ввести ограничения на значения:
sex='м' or sex ='ж'; education='среднее' or education='высшее'.
2) Создать таблички Образования, Полы, Соцстатусы и привязать к Клиентам через внешний ключ.
3) Как в п1, но ограничения реализовывать в окошечках и формочках, через которые данные вводятся?
4) п1+п3 вместе?
5) ваш вариант
Спасибо