web семенары

[ilovb]

Сегодня каждый дебил считает, что не куря теории можно полистать мануал к MySQL с PHP и пилить БД.

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

[valexey_u]

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

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

Гм... Кажется я начинаю понимать почему тебе понравилась Lua :-)

[ilovb]

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

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

Я имею в виду вырожденную модель, когда данные "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 равны соответствующим значениям. Значения помещаются в колонку, предназначенную для значений соотв. типа.
Ясное дело, что это охрененно неэффективный способ хранения. Но, увы, именно он даёт полную гибкость, динамическую изменчивость модели. Полиморфизм, которого хочется.

А полная гибкость и не нужна никогда. Структура БД строится не от данных, а от задачи. Делите весь набор свойств на статическое и динамическое подмножество и все. То что гарантированно будет статическим пихаете в колонки. Динамические свойства пихаете в структуру типа приведенной мной.

[ilovb]

Гм... Кажется я начинаю понимать почему тебе понравилась Lua :-)

И почему?

[valexey_u]

Гм... Кажется я начинаю понимать почему тебе понравилась Lua :-)

И почему?

Дык, эта… Все есть таблица же. А все остальное эмулируется через таблицы :-)

[ilovb]

Сравнение забавное, но таблицы РСУБД и таблицы Луа - это все же разные вещи. Ибо в реляционке вся суть в SQL, а не в самих таблицах.

Но с другой стороны в Луа методика использования таблиц похожа да...

ps Возможно потому мне таблицы Луа так легко дались...

[ilovb]

Блин valexey, кажется ты в самую точку попал Что то я раньше не задумывался о Луашных таблицах в таком контексте. Действительно способ построения абстракций один и тот же. Хм...

[alexus]

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

Посмотрел... и... увидел...
Да, всё хорошо, но

• Неудобная/непривычная запись (мелочь);
• Неполное описание атрибутов (серьёзно).

Чтобы дополнить атрибуты/характеристики, то должны быть...

• тип характеристики (числовой: целый, вещественный; строковый; дата_время... множественный(?))
• единицы измерений характеристики ('шт.', 'г', 'л', 'г/м3', и пр.)
• перевод ед. измерения (в другой таблице... но надо)
• обязательность характеристики (nullable)

... а в некоторых случаях и этого мало, и нужна ссылка на регламентирующий данный узел документ (ISO, ГОСТ, ОСТ, ТУ).
Недостатком является и то, что значения (в таблице значений) должны хранится в строковом виде, а, следовательно, к ним напрямую неприменимы операторы SQL... вроде MAX, MIN, AVG и т.д. По той же причине значения не могут быть ссылками...

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

Но такой вариант (с указанными выше ограничениями/замечаниями) является вполне себе рабочим... Его недостаток только в том, что таблица значений будет громоздкой... Например, если в среднем один узел описывается 10 характеристиками, до для 1 000 000 объектов этого узла, будем иметь 10 000 000 значений характеристик. Для современных СУБД - это не те объёмы, чтобы говорить о "тормозах"...

PS. Если из таблицы характеристик, убрать суррогатный ключ, то и таблица станет... проще, и естественный ключ <название характеристики> мигрирует в таблицу значений, сделав её более осмысленной и удобной... исключив лишний JOIN из запросов на выборку.

[alexus]

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

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

Илья Евгеньевич... это как-то совсем несерьёзно... Соединение таблиц в запросе... не проблема даже для студентов... (а для кого проблема... для тех существует VIEW).
И множественность классификаций тоже решаема... аналогичным способом.
Если говорить о реальных недостатках выборки, то она, конечно, есть... Например, мы хотим получить объект некоторого класса (элемент узла) вместе с его характеристиками... то получим выборку, где объект будет продублирован для каждой своей характеристики... и никак иначе. На клиенте это надо будет... обрабатывать. Нетрудно, но... это реальный минус.

[ilovb]

Ну я показал только общую структуру. У Ильи то как я понял уже на этом этапе проблема возникла.

[alexus]

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

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

Вот он критерий... определяющий выбор... (я прав?)

[alexus]

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

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), возможно, это что-то кохановское...
Разумеется, изврат, что для любого поиска придётся загружать всё содержимое таблицы и обрабатывать библиотекой..

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

А нехорошая жизнь... от извратов... вестимо...

Код: [Выделить]

На следующей  планете  жил  пьяница.  Маленький принц пробыл у него
совсем недолго, но стало ему после этого очень невесело.
     Когда он  явился  на эту планету,  пьяница молча сидел и смотрел на
выстроившиеся перед ним полчища бутылок - пустых и полных.
     - Что это ты делаешь? - спросил Маленький принц.
     - Пью, - мрачно ответил пьяница.
     - Зачем?
     - Чтобы забыть.
     - О чем забыть? - спросил Маленький принц; ему стало жаль пьяницу.
     - Хочу  забыть, что  мне совестно,  - признался  пьяница и  повесил
голову.
     - Отчего же  тебе совестно?   - спросил Маленький  принц, ему очень
хотелось помочь бедняге.
     - Совестно пить!  - объяснил пьяница, и больше от него нельзя  было
добиться ни слова.
     И Маленький принц отправился дальше, растерянный и недоумевающий.
     "Да, право же, взрослые очень,  очень странный народ", - думал  он,
продолжая путь.

[alexus]

Ну я показал только общую структуру. У Ильи то как я понял уже на этом этапе проблема возникла.

Нет... проблема возникла ещё раньше... IMHO.

[ilovb]

Недостатком является и то, что значения (в таблице значений) должны хранится в строковом виде, а, следовательно, к ним напрямую неприменимы операторы SQL... вроде MAX, MIN, AVG и т.д. По той же причине значения не могут быть ссылками...

Не обязательно. Например в 1С так сделано:
Колонки таблицы хранящей значения характеристик:
1. Ссылка на объект
2. Ссылка на характеристику объекта
3. значение типа булево
4. значение типа число
5. значение типа дата
6. значение типа строка
7. значение типа ссылка

Т.е. под значение выделено 5 колонок.
Есть небольшая избыточность, но это не страшно. Тем более что можно хранить любой тип. Этакая вариантная запись у них.

[alexus]

Недостатком является и то, что значения (в таблице значений) должны хранится в строковом виде, а, следовательно, к ним напрямую неприменимы операторы SQL... вроде MAX, MIN, AVG и т.д. По той же причине значения не могут быть ссылками...

Не обязательно. Например в 1С так сделано:
Колонки таблицы хранящей значения характеристик:
1. Ссылка на объект
2. Ссылка на характеристику объекта
3. значение типа булево
4. значение типа число
5. значение типа дата
6. значение типа строка
7. значение типа ссылка

Т.е. под значение выделено 5 колонок.
Есть небольшая избыточность, но это не страшно. Тем более что можно хранить любой тип. Этакая вариантная запись у них.

Да, но и SELECT'ы тоже надо настраивать... Если я хочу найти объект(ы) с максимальным значением характеристики, то... по какому из пяти полей искать?..