Удивительный контрпример неприменимости как ООП так и Relation Database.(Прочитано 24413 раз)
Нашел (Если будет интерес, скажу где) Чудный контрпример НЕПРИМЕНИМОСТИ как ООП(UML) так, и, что меня поразило больше, концепций Е.Кодда. Притом, что автор занимался  совсем другими вещами, и к флудерам, никакого отношения не имел, и не знал о существовании оных.  
КОНТРПРИМЕР: База данных МВД:)  найденные вещи.  Поользователь должен найти свою шапку (костюм в оригинале), среди украденных и конфискованных вещей, по базе. Проблема в том, что как для миллиционера, так и для пойманного перекупщика две шапки 1995 года, фабрики Красный богатырь, совершенно равнозначны.  А если их сотни, тысячи? Как  мне найти среди них  свою шапку по базе, а если там не только шапки, а еще и всякая всячина? (Мы говорим о текстовой базе, условно у нас нет картинок и фотографий) От себя добавлю, где здесь классы? объекты, методы, поля  классов?  
« Последнее редактирование: 30 Ноября 2009, 12:43:27 от ivanoval »



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

Или скажите какую травку курили, может, если покурить ее, то сразу будет ясно, что же Вы имели в виду :) А то не понятно, что о чем Вы спрашиваете.
« Последнее редактирование: 28 Ноября 2009, 23:02:17 от Galogen »



Уровень вашей культуры дисскурсий, меня не поразил.  Этот человек, в отличии от вас, признанный гений, а вы и я нет, увы.



ivanoval. Можно чуть понятнее? В Вашем сообщении много эмоций, но мало информации. Вы можете точнее сформулировать как задачу, так и ограничения?



Уровень вашей культуры дисскурсий, меня не поразил. 
Меня он тоже не поражает :)

Цитировать
Этот человек, в отличии от вас, признанный гений, а вы и я нет, увы.
Вы прямо загадками говорите

Вы вопрос сформулируйте, или идею того, что Вы хотите донести до аудитории. В чем проблема, я так и не понял:
проблема идентификации шапок Красный богатырь?
или проблема, что МВД не умеет создавать реляционные модели данных или использовать ООП?

 ;D



ПРИМЕР: База данных ПОЕЗДА  ПОЛЯ время прибытия, время отбытия. Номер поезда. Методы  Прибыл, отбыл. Хочу найти каким поездов поехать в прагу?
КОНТРПРИМЕР База данных украденных вещей (всех подряд, разделенных может только на категории не больше). ????? хочу найти СВОЮ шапку (Дополнительные ограничения: 1) визуальных материало в в базе нет 2.Никто не знает УНИКАЛЬНЫЕ  параметры моей шапки, и не кому они не интересны, хотя структуру  объекта можно сделать сколь угодно сложной /проектировщик может/  Так как мне найти мою шапку?  Проблема в том что здесь граница применения как ООП так и RDBMS, так вот.  
« Последнее редактирование: 28 Ноября 2009, 23:14:29 от ivanoval »



КОНТРПРИМЕР База данных украденных вещей (всех подряд, разделенных может только на категории не больше). ????? хочу найти СВОЮ шапку (Дополнительные ограничения: 1) визуальных материало в в базе нет 2.Никто не знает УНИКАЛЬНЫЕ  параметры моей шапки, и не кому они не интересны, хотя структуру  объекта можно сделать сколь угодно сложной /проектировщик может/  Так как мне найти мою шапку?  Проблема в том что здесь граница применения как ООП так и RDBMS, так вот. 
Не вижу связи. Как минимум - время попадания обьекта в базу - известно. Место - тоже известно. Обьект в базе  МВД будет содержать целый ряд признаков, предназначеных для оказания помощи при поиске предмета.



Беда не в том что информация не структурирована. Проблема в том, что при этом гипотетический select  возвращает совершенно неопределенный, возможно неправильный, ответ. И это как бы фундаментальное свойство повидимому (не знаю как сказать понятнее). В частности попытки решить эту проблему методом дистиляции смысла, признаны после 50 лет, ага, неразрешимыми. И это значит что существующая ныне програмная порадигма, имеет ограничения, на весьма тривиальном уровне. Что мне очень грусто и меня немного шокирует, поэтому я  и  кажусь вам эмоциональным.



Да место известно, это торговец ВАНЯ Б.  у которого такого барахла вагона  три. И везут ему его со всего СНГ.  Время тоже известно, его ловят в 2012 году а шапку у мен крадут в 2008.

Модератор: попрошу не плодить последовательность своих сообщений, если это не ответы разным людям по разным темам
« Последнее редактирование: 29 Ноября 2009, 00:32:02 от Galogen »



Единственное за что я могу зацепится это описание моей шапки.  Индувидуальное описание есть XML пусть будет.  Уникальные свойства там есть или нет бог знает. И не UML ни ООП ни SQL  мне тут совершенно не попутчики, увы получается так.
« Последнее редактирование: 29 Ноября 2009, 00:02:14 от ivanoval »



И не UML ни ООП ни SQL  мне тут совершенно не попутчики потому, что запрос к подобной базе не гарантирует мне ни только результат, что было бы еще ничего; Но может выдать и не правильный результат, что намного хуже.
« Последнее редактирование: 28 Ноября 2009, 23:57:43 от ivanoval »



ivanoval, не могу понять, что вы пытаетесь донести. Причем тут ваша шапка, которую у вас украли, а потом нашли. И причем тут концепции ООП и реляционных отношений.

Скажите, а если перед вами выложат 100 шапок Красного октября среди которых одна - ваша, как вы ее найдете?



Есть проблема (в научном смысле) идентификации. Эта проблема существует независимо от Кодда и ООП. Её надо решать, если вы её не можете решить безо всяких Коддов, то они вам не помогут.

Выработать релевантный набор идентификационных признаков — это типичная творческая (исследовательская) задача, даже на бытовом уровне.

Эд хороший вопрос задал.



ivanoval, возможно, проблема не в задаче, а в том, что Вы считаете исходной данностью, а что следствием. Поясню.

Ваш подход: Имеется некая структура данных (база вещей или поездов), нужно понять, как с ее помощью решить пользовательскую задачу (найти что-то).
Не удивительно, что решение не находится. База данных - всего лишь модель, абстракция, имеющая свою ограниченную область применения.

Что я хочу вам предложить - пойти от обратного. Есть конкретные пользовательские потребности (найти что-то), нужно понять, какой должна быть база данных, чтобы это было возможно сделать? Для начала можно смоделировать идеальную базу, потом учесть ограничения, придумать для чего-то альтернативу и т.п.

И на UML тут как раз не стоит грешить :) Вы начали сразу с классов и данных, а в UML есть еще и такая чудесная вещь, как Use Cases, которая как раз и предлагает сначала ответить на вопрос, что же хочет получить пользователь, а потом уже решать какими средствами он этого добьется.



"...Имеется некая структура данных" - нет, имеется набор разнородных объектов.
"...Есть конкретные пользовательские потребности" - тогда место шапок мы классифицируем пользовательские потребности. Мы придем к тем же проблемам, только будем складировать пользователей.
"...придумать для чего-то альтернативу и т.п.пользователей?" - это не гарантирует результат и его правильность.
"...Выработать релевантный набор идентификационных признаков..." -для этого случая в известных мне концепциях невозможно, вы знаете как это сделать?
"...Скажите, а если перед вами выложат 100 шапок Красного октября ... как вы ее найдете?" -  по уникальным признакам




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19