Вопрос про БД.
Недавно с этим столкнулся…
Вообщем приложение(клиент) юзает БДБЕЗсвязей(один ко многим, многие ко многим, один к одному).
В чем выгода такого подхода???
Вопрос про БД.
Недавно с этим столкнулся…
Вообщем приложение(клиент) юзает БДБЕЗсвязей(один ко многим, многие ко многим, один к одному).
В чем выгода такого подхода???
Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.
24 июля 2009 в 4:04
У него было четверо детей и шесть внуков….
Это все из за его увлечения БД…
23 июля 2009 в 19:04
лично с ним знаком не был, судя по работам и чтов плагиате вроде замечен не был получается умный был мужик.
23 июля 2009 в 16:01
Нгамдкхе Кверос
А что ты думаешь по поводу Эдгара Ф. Кодда ?
Надо сделать акцент на том что везде используются суррогатные ключи
23 июля 2009 в 15:00
"Скорость при поиске в одной единственной таблице много выше если она не связана с другими табл."
есть совсем лажовая субд то конечно,
если нет то могут быть варианты по организации таблиц, характеру данных и характеру запросов. если поиск по полю по которому индекса нет то скорость пропорциональна объёму данных, а без связей это поле может дублироваться много раз, при связи же ты находишь поле единожды и лишь ссылки на него в другой таблице, кодд не хернёй страдал а умную мысль думал, кабы мысль была глупая всебы так и сидели на обычных записях всех полей в одной единственной таблице. в случае изъятия работает много быстрей из-за кеширования, и т.д. и т.п.
23 июля 2009 в 12:05
>>>Если бы эту тему увидел Код он бы точно перекрестился
Знаешь, я думаю Код уже никогда не увидит этого…)
23 июля 2009 в 12:05
Эдгар Ф. Кодд умер от сердечного приступа у себя дома во Флориде на острове Вильямс в возрасте 79 лет в пятницу 18 апреля 2003. У него было четверо детей и шесть внуков.
23 июля 2009 в 12:04
Скорость при поиске в одной единственной таблице много вышеесли она не связана с другими табл.
23 июля 2009 в 11:01
Это человек создавший реляционную модель данных. Которая впервые была реализована в СУБД System R фирмы IBM.
23 июля 2009 в 11:01
ммм понятно… )))
23 июля 2009 в 10:04
Эдгар Франк «Тед» Кодд.
23 июля 2009 в 9:01
Даша, who is Код?
Так то теория.. а то практика..
22 июля 2009 в 22:02
зависит от уровня избыточности, иногда за счёт разбиения на таблицы существенно сокращается и число записей и их размер от чего и скорость возрастает.
22 июля 2009 в 16:00
Если бы эту тему увидел Код он бы точно перекрестился. Зачем так извращаться над реляционной моделью!!! Как же нормализация и все что связано с теорией реляционных отношени?!!
22 июля 2009 в 14:02
Преимущество отсутствия связей на уровне БД – скорость, недостаток – потом работу найти трудно, после того как база помреть
Кризис, хуле 
20 июля 2009 в 10:05
да скорее всего просто дали задание какому-нибудь студенту в качестве курсовика и тот сваял как смог, случаев сплошь и рядом, а вы пытаетесь искать какой-то глубинный смысл…
19 июля 2009 в 11:00
естественно этот сценарий для особых случаев.
19 июля 2009 в 0:00
> иногда имеет смысл пожертвовать внешними ключами и целостностью в угоду производительности.
Только если замерять выигрыш, и оценить риски
15 июля 2009 в 22:05
иногда имеет смысл пожертвовать внешними ключами и целостностью в угоду производительности.
15 июля 2009 в 20:02
Тихо молча никакого ограничения не будет. Формально он есть, а фактически не проверяется. Так в mysql с таблицами не на InnoDB
15 июля 2009 в 20:00
Как это — не будут? Внешний ключ прежде всего — constraint, и он работает, если поддерживается СУБД.
15 июля 2009 в 18:04
Внешние ключи в mysql создаются без проблем, но реально работают только с таблицами InnoDB. По умолчанию для таблиц используется MyISAM, а при явном указании все равно может создать таблицу с MyISAM из-за неправильной конфигурации.
15 июля 2009 в 18:02
Зачем так необходимо делать внешние ключи, если они работать не будут?) Не все СУБД поддерживают корректную работу внешних ключей.
15 июля 2009 в 18:02
В FIREBIRD ВНЕШНИЕ КЛЮЧИ ЕСТЬ И РАБОТАЮ
15 июля 2009 в 18:02
>>>Если БД mysql – то там есть некоторые сложности с внешними ключами.
Какие?
15 июля 2009 в 18:00
Должно работать, если поддерживать целостность. Главное, чтобы проиндексовано было. Но разработчик — идиот, несомненно. Внешние ключи делать НАДО, если они подразумеваются бизнес-логикой. Так что не бери в голову, а переделай всё на добрый лад
15 июля 2009 в 17:05
Да, вместо "обеспечения целостности " ) !
15 июля 2009 в 17:04
А тут должен быть какой-то плюс?
15 июля 2009 в 17:03
Если БД mysql – то там есть некоторые сложности с внешними ключами. Наличие явного указания связи между ключами в таблицах нужно для обеспечения целостности БД. Выборку можно делать с тем же успехом и без явных связей. Если в коде запросы к таблицам без каких-либо джоинов, то спрашивать надо у программиста, который это все наваял.
Как вариант, изначально все работало на файлах и массивах, а БД прикрутили позже "для галочки".
15 июля 2009 в 17:02
А поле N_F не является первичным ключом в первой таблице и внешним во второй?
15 июля 2009 в 17:02
>>>какой хитрый код ни пиши, все равно ничего не свяжется и не отфильтруется.
Я его вижу, прямо перед собой. И поверь это работает.
Технически таблицы связываются как бы "искуственно" уже в коде.
15 июля 2009 в 17:02
Для первой таблицы онявляется Primary key non autoincr…
Но для второйпросто полем(без всяких вторичных ключей для связки).
15 июля 2009 в 17:01
1 таблица !
++++++++++
|N_F |
|Name F |
|ReaL Name F |
2 таблица !
++++++++++
|N_address_F |
|Adress F |
|N_F |
15 июля 2009 в 17:01
F- фирма)!
15 июля 2009 в 17:01
Заметим что связей нет!Но работает…
15 июля 2009 в 17:01
Вариант "программер – идиот" исключен?
И о каких связях идет речь? Если нет полей, по которым можно связать строки двух таблиц, то какой хитрый код ни пиши, все равно ничего не свяжется и не отфильтруется.
N_F – что за зверь? похоже на ключевое поле для связи. В чем тогда проблема?
15 июля 2009 в 16:05
а можно для примера пару таблиц хотя бы привести… таких что там должны быть отношения, но их нет.
А то Вы лично мне мозг ломаете %)
15 июля 2009 в 16:04
Много таблиц но связей м/д ними вообще нет.
Фактически программеру пришлось писать "свой движок"
Даже элементарные фильтры в пару строчек ему пришлось писать в целые докторские))
Зачем так мучаться?Разве не проще создать связи??? Но нет …
зачем так делать просто не пойму…?
В чем может быть плюс такого подхода?
15 июля 2009 в 16:03
Приложение (справочник по фирмам города)
В нем на Firebird" база данных.