|
|
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
guest_20040621> для случая когда у одного Кастомера может быть несколько Адресов такая схема вполне > применима Вы напрасно получаете деньги за проектирование баз данных. вы напрасно пытаетесь меня провоциравать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:28 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2Все базы могут хранить данные. Следовательно все базы данных правильные .{!!!!!!}Но некоторые их них не соответствуют реляционной модели, некоторые ненормализованы. Вот тут Вы АБСОЛЮТНО ПРАВЫ, Коллега ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:29 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2Фёдоровproposed amendmentguest_20040621 Вы не видите? Открываете страницу, две первые таблицы: Addresses и Customers. Все, дальше можно не смотреть. А Вы и есть Федоров Richmond VA? для случая когда у одного Кастомера может быть несколько Адресов такая схема вполне применима Супруги пришли покупать автомобиль. На двоих. Такое наверняка должно быть. Анесколько адресов должны отличаться признаками. Например, адрес для уведомления, адрес для доставки. Причем они могут совпадать. Не так уж трудно это завести в структуре базы. Не так уж трудно всю её исправить. Мы же обсуждаем предложенный вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:29 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
ФёдоровОна применима, но она не правильная. Если следовать логике автора, предложившего таблицы Cars_for_Sale и Cars_Sold, то тогда нужна ещё, как минимум, одна - Cars_Returned. 1 все определяется рамками ТЗ - например часто машины проданные через комиссионку не принимаются обратно в магазин, но можно их опять поставить на комиссию - вернуть в продажу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:33 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Mr MarmeladCat2, Коллега Cat2 ну хоть вы наберитесь уважения и внимания к собранным годами системам. Поверьте - они не просто ТАК там живут. ЕСТЬ где то необходимость в той или иной аттрибутике. Она ВАМ не видна. Примите ЭТУ аксиому если не хватает Вам доказательств что там в искусстве ОШИБОК НЕТ и быть не может. address_ID - ключ (правильно суррогатный) для обозначения уникальности записи. Не всегда удаётся адрес обозначить ДРУГИМ уникальным атрибутом. В Америке к промеру 123 Washington Street и Washington St, 123 и Wash. St - 123 могут обозначать как одну так и разные адреса. И ничего в этом такого нет что стоЯт они под уникальными айди 734, 823 и 1234. Четыре Adress_Line - это скорее традиция и удобство чем что либо ещё. Town_city - муниципалитеты State_county_province - расчитаны на Англоязычников (USA, CA, AUS) потомков пилигримов и понятное дело к конкретно республикам - регионам или что там у вас никакого отношения не имеют. Но поучиться у этих ребят британцев вам ой как следовало бы... Хотя бы терпимости к другому ПРАВИЛЬНОМУ мнению За аксиому я ничего не принимаю никогда. Вот пристали с address_ID! Я же написал, что он может иметь место быть, если нужно хранить несколько адресов. Но тогда нужен признак, отличающий адреса. Вы хотите мне сказать, что 123 Washington Street и Washington St, 123 и Wash. St - 123 - это Country? Вы хотите сказать, что справочники для выбоа "USA, CA, AUS" - лишние? И без них все все всегда без ошибок ведут? ================ Мы будем базу обсуждать или политкорректностью заниматься? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:38 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
ФёдоровСупруги пришли покупать автомобиль. На двоих. Два имени и два адреса должны быть указаны в свидетельстве о собственности на машину. и совершенно нормально - свидетельство о праве собственности законченный документ не изменяющийся во времени (при изменениях будет выпущено новое свидетельство) - на него не могут распространяться требования к нормализации структуры БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:40 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2 ================ Мы будем базу обсуждать или политкорректностью заниматься? это не база - это модель, любая модель не тождественна обстоятельствам реального мира а просто обладает степенью подобия ему, причем в тех пределах: 1 которых требует воплощаемая в модели парадигма (та или иная или их комплекс) 2 которых позволяет достичь материал моделирования (нотация записи, как здесь) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:46 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2За аксиому я ничего не принимаю никогда. Ну примите хоть как теорему что в моделировании ОШИБОК НЕТ и БЫТЬ НЕ МОЖЕТ... Моделирование - прежде всего искусство, а потом наука. Тут будет важнейшим фактором НРАВИТСЯ - НЕ НРАВИТСЯ , потом КРАСИВО - НЕ КРАСИВО, а никак не ПРАВИЛЬНО - НЕ ПРАВИЛЬНО Cat2 Вот пристали с address_ID! Я же написал, что он может иметь место быть, если нужно хранить несколько адресов. Но тогда нужен признак, отличающий адреса. А нету такого - как бы мы не старались... Даже в налоговых документах - НЕТУТИ... и всё тут. address_ID и больше ничего Cat2 Вы хотите мне сказать, что 123 Washington Street и Washington St, 123 и Wash. St - 123 - это Country? Вы хотите сказать, что справочники для выбоа "USA, CA, AUS" - лишние? И без них все все всегда без ошибок ведут? Адреса указанные выше - это линии адресов по определению в Англоязычных странах. Так у них принято. могут поставить как хотят. Стандартов нет и не должно быть. На такой системе все их почтовые службы работают. Сначала посылают в почтовый код (ПОЧТОВЫЙ ИНДЕКС) по Вашему. Postal Code - в Канаде Австралии Великобритании. Zip Code - в США. Опять же стандарта нет. У нас например может быть пяти или девяти-значный Zip Code. Например в одном городе может быть десятки zip code а можт не быть ни одного. Совмещаться в одном zip kode два города и так далее... Провинцию у нас называют Условно - это ГРАФСТВО (county) в Канаде же Province - это означает ШТАТ (республика) и масса ещё чего чего Вам может показаться НЕ МОЖЕТ БЫТЬ,,, анннет - МОЖЕТ. так вот почтальён один сам по себе знает где на его участке тот или иной адрес. И есть ли вообще. А кроме него ни одна система не догадывается ЧТО ТАМ за тем столбом... Cat2 Мы будем базу обсуждать или политкорректностью заниматься? Вот тут Вы мне особенно мне нравитесь, Коллега... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:58 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
> вы напрасно пытаетесь меня провоциравать Признайтесь, Вы ведь комментарий написали не просто так? ;) Ну ведь на самом деле здесь нечего обсуждать. Абсолютно тупая схема с абсолютно детскими ошибками. На месте авторов мне было бы стыдно выкладывать это в свободный доступ. Я даже предположить не могу, какой идиот их учил проектированию. Нормальные формы, атомарность, целостность, непротиворечивость и пр. - в любом букваре по проектированию БД об этом пишут чуть ли не в первой главе. Похоже, с букварей им и нужно начинать. Консультанты хреновы, блин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:58 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
proposed amendment, Любая база = модель. И должна отображать скорее не обстоятельства мира, а наши требования по "учету" этих обстоятельств ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 18:59 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
MasterZiv > address_Line_1 - address_Line_4. Это из разряда юмора. Это - да . Плюс ещё же есть otherDetails ! В общем я тоже поржал AddressLine_1 > AddressLine_4 это нормально... 103009, Россия, Москва Брюсов переулок, д. 12, кор. 4, кв. 5 запишите, как если бы, например, отправляли в Турцию... справитесь? а вот так? 34349, Balmumcu, ENKA BINASI, Besiktas - Istanbul, Turkey запишите по-Русски и занесите в вашу супер-нормальную базу по полям индекс-страна-населенный_пункт-улица и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:11 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2proposed amendment, Любая база = модель. И должна отображать скорее не обстоятельства мира, а наши требования по "учету" этих обстоятельств конечно база это модель в той или иной степени объективно отображающая объекты материального мира и их отношения схема (как по ссылке) это тоже модель - только реализованная другими инструментами и материалами. вопрос не в этом вообще... выше по топегу видно отчего сыр-бор... для меня, например, совсем не очевидно, что критерием объективности (подобия) модели могут служить "ваши" требования по учету "ваших" обстоятельств... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:17 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
proposed amendmentФёдоровСупруги пришли покупать автомобиль. На двоих. Два имени и два адреса должны быть указаны в свидетельстве о собственности на машину. и совершенно нормально - свидетельство о праве собственности законченный документ не изменяющийся во времени (при изменениях будет выпущено новое свидетельство) - на него не могут распространяться требования к нормализации структуры БД. Нормализация относится к реляционному отношению, а не к БД. Если выполнять нормализацию исходя из функциональных зависимостей, то вполне возможно, что отношение "свидетельство" в идеализированном случае будет нарушать какие либо НФ и в конечном итоге будет содержать как бы противоречивые данные. Если пользоваться ER моделированием, то свидетельство, это единая сущность и выполнять её декомпозицию нет смысла, ибо как в свидетельстве прописано (даже с ошибками), так оно и есть на самом деле. Например есть в свидетельстве паспортные данные. Интуитивно ясно, что ФИО функционально зависит от номера паспорта, который в свою очередь зависит от номера свидетельства (PK). По букве науки имеем нарушение 3НФ, и надо выполнить декомпозицию отношения. Но это приведёт к первичному учёту паспортов, который в данном случае нам нафиг не нужен. А хуже того, интуиция нас может подвести, так что в один прекрасный момент номер паспорта окажется не PK, а лишь его частью. Или выяснится, что какой то балбес много лет назад допустил ошибку в фамилии владельца и выдал свидетельство с ошибкой. И что тогда? Если мы исправляем ошибку в паспорте, то искажаем данные в старом свидетельстве, если оставляем как есть, то выписываем новое свидетельство с той же ошибкой. Косяк! Короче, если в первичных документах есть нарушение НФ и дублирование данных, то и в БД от неё будет сложно уйти, или придётся делать идеализированную БД, которая в реальной ситуации не сможет хранить необходимые данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:20 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
explaКороче, если в первичных документах есть нарушение НФ и дублирование данных, то и в БД от неё будет сложно уйти, или придётся делать идеализированную БД, которая в реальной ситуации не сможет хранить необходимые данные. +1 мало того, что согласен, это ИМХО очевидно... наверное только стремлением создать "идеализированную БД" можно объяснить высказывания некоторых участников разгоревшейся дискусии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:28 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad... в моделировании ОШИБОК НЕТ и БЫТЬ НЕ МОЖЕТ... Моделирование - прежде всего искусство, а потом наука. Тут будет важнейшим фактором НРАВИТСЯ - НЕ НРАВИТСЯ , потом КРАСИВО - НЕ КРАСИВО, а никак не ПРАВИЛЬНО - НЕ ПРАВИЛЬНО Не согласен. Если модель не отражает существенных свойств объекта, то она неправильная (или недостаточно точная, если хотите). В моделировании конечно есть место творчеству и субъективному вкусу, но по большей части это работа по методике и дедукция. Собрали сведения - проверили модель - обобщили - подкрутили. Получилась простая и понятная модель, которая достаточно точно отражает нужные свойства объекта, хорошо. Получилась кривая запутаная, но опять же достаточно точная модель, плохо, но не смертельно (дело вкуса). Модель не отражает нужные свойства объекта с должной точностью, значит такой моделью нельзя пользоваться для решения поставленой задачи, делаем другую модель. Cat2За аксиому я ничего не принимаю никогда. Теория не может сущетствовать без аксиом. Это доказано, так что придётся смириться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:43 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
proposed amendment запишите по-Русски и занесите в вашу супер-нормальную базу по полям индекс-страна-населенный_пункт-улица и т.д. А я говорил, что надо нормализировать все и всегда? Вот, например, в базе налоговой (КЛАДР), все нормализовано. Им это надо обязательно и они могут. В реальности иногда проще не замарачиваться, особенно когда не надо делать выборок по аресам. Однако населенные пункты все же лучше в отдельное поле - легче искать. Кстати, не вижу принципиальных трудностей с турецким адресом. Если есть общирная перписка, то можно создать правила чередования полей традиционные для разных стран. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:47 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Cat2, я спорил не с вами, собственно... мне показалось излишне категоричным высказывание одного из участников про "абсолютно" неграмотную модель... точнее я его (высказывание... да и автора, собственно) не понял и переспросил - что он имел в виду... вы тоже обсуждаете схему с категоричных и идеализированных позиций... поясните - нафига тут в этой схеме разделение адреса большее чем предложено town_city и address_lines ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:58 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
2 expla: Ув Коллега explа как раз то что Вы определили как "методика и дедукция" и есть прежде всего искусство. Просто у гениальных художников и мастеров всё происходит с первого мазка, а у студентов худ колледжа - каждодневная упорная тренировка. Набивание Руки если хотите. Даже живое воплощение базы вышедшей из-под пера модельера - физическое воплощение - это чаще всего этап вижуализации и демонстрации идей, а не активная перепечатка кортинок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 19:59 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
Отличной аналогией в нашем случае модельном бизнесе будет именно профессия ХУДОЖНИКА - МОДЕЛЬЕРА. Ведь в конце концов "ГЛАВНОЕ ЧТОБЫ КОСТЮМЧИК СИДЕЛ" © ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 20:09 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
> запишите по-Русски и занесите в вашу супер-нормальную базу по полям Страна, административная или административно-территориальная или территориальная структура, языковые эквиваленты, правила адресации, язык респондента. Какие проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 20:16 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
guest_20040621Какие проблемы? это мне что все страны мира в голове держать? админитсративно территориальное деление, правила указания адресов и прочее вы на почте конверты отдельно турецкие, английские и сомалийские покупаете? там всего Куда (три-четыре линии) Кому (две-три линии) и все ах- да! еще Индекс и Марка, конечно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 20:25 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
> нафига тут в этой схеме разделение адреса большее чем предложено town_city и address_lines Например, чтобы корректно отображать любые объекты на карте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 20:27 |
|
||
|
Интересные модели БД!
|
|||
|---|---|---|---|
|
#18+
> это мне что все страны мира в голове держать? Базы данных, конечно же, придуманы дебилами для дебилов. Поэтому все всегда нужно держать в голове. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2008, 20:36 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35718198&tid=1542951]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
184ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 499ms |

| 0 / 0 |
