web семенары

[ilovb]

Если Илья опишет задачу с исходными данными и я решу ее за пол часа, то проблема отсутствует. 

ps В pdf слишком мало информации.

[ilovb]

Если я правильно понял проблему с запчастями, то делается это так:

таблица Запчасти:
[УникальныйНомер: Число, Наименование: Строка, Тип: Таблица "ТипыЗапчастей"]

таблица ТипыЗапчастей (какие бывают виды запчастей):
[УникальныйНомер: Число, Наименование: Строка]

таблица ПараметрыЗапчастей (какой набор параметров содержит каждый вид запчасти):
[УникальныйНомер: Число, Наименование: Строка, Тип: ТипыЗапчастей]

таблица ЗначенияПараметровЗапчастей (значения параметров для каждой конкретной запчасти):
[Запчасть: Таблица "Запчасти", Параметр: Таблица "ПараметрыЗапчастей", ЗначениеПараметра: Произвольный]

[ilovb]

Простую иерархию - да, легко... более, чем одним способом. Но если каждый узел иерархии имеет произвольное количество разных атрибутов... и атрибуты не всегда элементарных типов... то здесь и возникают проблемы.

У меня абстрактное мышление плохо развито.  Можно конкретный пример?

[alexus]

Простую иерархию - да, легко... более, чем одним способом. Но если каждый узел иерархии имеет произвольное количество разных атрибутов... и атрибуты не всегда элементарных типов... то здесь и возникают проблемы.

У меня абстрактное мышление плохо развито.  Можно конкретный пример?

Посмотрите статью. Там есть пример.
Пусть в БД должна хранится информация о разных видах товара (в статье: молоко и мебель, но можно развить пример различными видами автозапчастей... как у И.Е. Ермакова, или какими-то другими видами товаров...). Каждый вид товара имеет, наряду с общими, свой уникальный набор атрибутов, но при этом мы не должны утрачивать единой сущности "товар". Вот и возникает вопрос о том, как эффективнее реализовать структуру БД для хранения разных товаров.

[ilovb]

Тык смотрите выше...

[ilovb]

Если я правильно понял проблему с запчастями, то делается это так:

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

ps Надеюсь не нужно объяснять что любые желаемые данные элементарно вытаскиваются из этой структуры SQL'ем

[ilovb]

Но тут уже реляционка точно использовалась бы просто как ассебмлер - с таблицами вида "объект - признак - значение" и т.п.

Я вам открою страшный секрет. Именно так реляционная модель и строится 

[Илья Ермаков]

Судя по тому, что в этой pdf у вас действительно слабое представление о реляционной модели. Ибо такая картотека делается в SQL-СУБД элементарно. И я не увидел задачи в pdf. Какая задача то стояла?

Да я знаю, как она делается. Я ж говорю - на реляционке, как на ассемблере, можно сымитировать что угодно.
Например, качественные свойства из ФОК:
таблица-справочник вида [id | id свойства-родителя | название свойства ],
а дальше отношение n:n между таблицей описуемых объектов и таблицей-справочником свойств.
И т.п.
А потом клепать библиотеку для работы с этим хозяйством, поддерживать целостность, когда мне понадобится информация о конкретном объекте - собирать через JOIN-ы, и т.п.

Подзадача, для которой эта модель данных - просто поддержать каталог автомобилей и деталей, с возможностью классификации по многим критериям и отбора по разным признакам.

[ilovb]

Я вас не понимаю. Почему сымитировать? Это и есть нормальное проектирование в реляционной модели.

Так же можно сказать, что на CP можно сымитировать связанный список...

[ilovb]

Подзадача, для которой эта модель данных - просто поддержать каталог автомобилей и деталей, с возможностью классификации по многим критериям и отбора по разным признакам.

Значит я решил вашу задачу?: http://oberspace.dyndns.org/index.php/topic,308.msg12630.html#msg12630

[Илья Ермаков]

Но тут уже реляционка точно использовалась бы просто как ассебмлер - с таблицами вида "объект - признак - значение" и т.п.

Я вам открою страшный секрет. Именно так реляционная модель и строится 

Я имею в виду вырожденную модель, когда данные "137, Петров, Иван, Николаевич, 23.07.1987' будут отображены в виде:
[137, 1, NULL, 'Петров', NULL]
[137, 2, NULL, 'Иван', NULL]
[137, 3, NULL, 'Николаевич', NULL]
[137, 4, NULL, NULL, '23.07.1987']
- в такой таблице зафиксированы 5 фактов: что соответствующие поля объекта с id=137 равны соответствующим значениям. Значения помещаются в колонку, предназначенную для значений соотв. типа.
Ясное дело, что это охрененно неэффективный способ хранения. Но, увы, именно он даёт полную гибкость, динамическую изменчивость модели. Полиморфизм, которого хочется.

[Илья Ермаков]

Значит я решил вашу задачу?: http://oberspace.dyndns.org/index.php/topic,308.msg12630.html#msg12630

Да, но это коряво
Это требует массы объединений.
Любой запрос информации по любому объекту сведётся к сборке множества его признаков из отношения многие-ко-многим.
Не нравится мне всё это.

Кроме того, при использовании XML-СУБД я поднял карточку - и сразу отдаю её клиентской части для отображения. Тут я должен завести ещё промежуточные формы хранения, всё равно придумать формат, в котором я это отдам клиентской части (например, отображу в JSON)... И т.п.

[Илья Ермаков]

Вот живой пример, как извращается народ, не желая связываться с негибкими структурами РСУБД, когда нужно сделать быстрый проект, но при этом с кучей изменяющихся признаков:

INSERT INTO `spy` (`id`, `created`, `data`) VALUES
(212, '2012-08-18 10:12:54', 'a:26:{s:8:"pers_fio";s:54:"Петрова Анастасия Павловна";s:13:"pers_birthday";s:19:"20 Марта, 1988";s:11:"pers_nation";s:4:"РФ";s:9:"pers_city";s:12:"Москва";s:10:"pers_metro";s:22:"Семеновская";s:10:"pers_phone";s:15:"8-926-0000000000";s:14:"pers_phone_add";s:0:"";s:10:"pers_email";s:20:'xxxxxx@inbox.ru";s:18:"pers_family_status";s:35:"не женат/не замужем";s:20:"pers_family_children";s:1:"-";s:8:"edu_main";a:1:{i:0;s:88:"Москва, МПГУ, социология,экономика и право";}s:8:"job_city";a:2:{i:0;s:12:"Москва";i:1;s:12:"Москва";}s:11:"job_company";a:2:{i:0;s:29:"Xxxx Банк";i:1;s:48:"Московский Xxxxxx Банк";}s:11:"job_profile";a:2:{i:0;s:14:"финансы";i:1;s:14:"финансы";}s:11:"job_in_date";a:2:{i:0;s:4:"2010";i:1;s:4:"2012";}s:12:"job_out_date";a:2:{i:0;s:4:"2012";i:1;s:34:"по настоящее время";}s:8:"job_prof";a:2:{i:0;s:60:"Старший специалист";i:1;s:70:"кредитный аналитик (автокредитование)";}s:8:"auto_lic";s:1:"n";s:8:"auto_car";s:0:"";s:7:"exp_spy";s:1:"n";s:11:"exp_company";s:0:"";s:11:"exp_project";s:0:"";s:7:"exp_rec";s:1:"y";s:13:"exp_rec_phone";s:1:"y";s:9:"exp_start";s:24:"в любое время";s:8:"exp_shed";s:197:"С понедельника по воскресенье, день. (дни недели меняются в зависимости от графика на основном месте работы)";}')

Т.е. они вообще хранят все признаки объекта в одном поле РСУБД в каком-то своём формате... Поскольку проект на Kohana Framework (PHP), возможно, это что-то кохановское...
Разумеется, изврат, что для любого поиска придётся загружать всё содержимое таблицы и обрабатывать библиотекой..

Но не от хорошей жизни такие извраты

(данные, разумеется, обезличены)

[ilovb]

Значит я решил вашу задачу?: http://oberspace.dyndns.org/index.php/topic,308.msg12630.html#msg12630

Да, но это коряво
Это требует массы объединений.
Любой запрос информации по любому объекту сведётся к сборке множества его признаков из отношения многие-ко-многим.
Не нравится мне всё это.

КОРЯВО? O_o    Да... весьма странные у вас представления о реляционной модели.

Масса объединений? Сборка множества? Ничего что это и есть метод реляционных СУБД?

[ilovb]

Вот живой пример, как извращается народ, не желая связываться с негибкими структурами РСУБД, когда нужно сделать быстрый проект, но при этом с кучей изменяющихся признаков:

Илья, я видел вещи и пострашнее. Настолько страшные, что вам и не снилось. Например когда в РСУБД таблицу заполняют данными не вертикально, а горизонтально...
Но это все ошибки в генах у недоразработчиков (коих больше всего среди web-типакодеров)
Почему вы измеряете реляционку идиотами?