ссылко: "Я открыл гугл и набрал слова “математика развернуть стрелочки”. Ба! Википедия! Теория категорий и ко-алгебра! Теперь я точно знаю, что есть решение проблемы!"
Хуита какая-то. Возьмите старинную книжку "Предложения комитета CODASYL по организации баз данных" и убедитесь, что тов. Эрик в упрощенном виде ее пересказывает. Далее возьмите выжившую db* (или уже не выжившую?) и убедитесь, что внутре оно реляционное.
Но смысл у всей этой функциональной ахинеи есть: так как SQL Server от лидеров отстал, кажется, навсегда, то лучше уж подсадить на функциональщину, чем ждать, когда все просто тихо свалят.
Э... Двойственность, двойственность... Я, конечно, тему баз слабо знаю - но обычно если где всплывает такая двойственность - то разница между двойственными вещами ровно на замену базиса. Т.е., получается, что если развернуть ссылки - получаем опять же обычную нормализованную реляционную базу, только таблицы и индексы другие?
Там реляционная база не получится. После разворачивания ссылки представляют собой вместо скаляра множества, т.е. в одно поле их не засунешь.
Собственно, достаточно разрешить поля-вложенные таблицы и мы то самое и получим. Смех в том, что их эффективная реализация все равно может оказаться обычной реляционной, единственное отличие - что внешне это будет более удобно для использования.
Речь идёт скорее всего про синтаксис описания связей и запросов, чтобы как-то убрать явные IDs. Скажем OQL уже позволяет не писать в явном виде joins, а если ещё и синтаксис сохранения избавить от ID, то вроде как чуть проще.
По большому счёту несколько раздражает тавтологичность использования FROM X INNER JOIN Y ON X.ID = Y.PARENT_ID когда и так других ключей и связей между X и Y нет. Дура база могла бы и сама догадаться. В мускуле есть X JOIN Y on (KEY_ID), и всё равно "on (KEY_ID)" незачем.
А почему именно такой объект? Отношение-то M:N, можно и обратно.
> Таким образом, заявил Эрик, из моего простого объекта получилось вдруг три новых, в которые добавились какие-то новые сущности (идентификаторы), не имеющие к реальному объекту никакого отношения
Вообще-то авторы могут быть общими у разных книг. Более того, могут быть авторы и без книг. Для отчётов авторов надо как-то идентифицировать. Можно, конечно, по имени в паспорте. Но тогда всё равно надо тягать с этим ID все данные по авторам. Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
> плюс нужно писать дополнительный код, осуществляющий трансформацию
Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
> В результирующем “реляционном” подходе наоборот - потомок всегда знает о том, кто его родитель.
Бред. Авторы и книги -- кто чей предок и потомок? И прекрасно обходятся без прямых ссылок на себя, тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей. И 1:N тоже можно сделать так.
Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее. C 1:N и двумя таблицами все проще.
Для книг будут существовать стрелки "автор книги", для автора - "книги автора". Раз мы говорим о стрелках, мне кажется неправильным выделять какое-то их направление отдельно, если мы говорим о внешнем представлении, а не о хранении. Внутри пусть хранят как им самим удобнее, главное - что мы видим снаружи.
Если уж зашла речь за теорию категорий, почему бы тогда сразу не пойти дальше и не заменить поля стрелками?
no subject
alexey raga (from livejournal.com)2010-12-11 02:01 am (UTC)(link)
Я тут отвечу на что смогу. На самое смешное, наверное :) Кроме того, жена уехала в Канберу болеть за триатлон Iron Man, а мне просто скучно :) Поэтому буду много писать. Надеюсь, писать буду не очень скучно :) Цель - немножечко объяснить точку зрения, а не навязать и переубедить, конечно. Объяснить "почему" и когда это оправдано.
Вопросов, действительно, достаточно, и Эрик рассказал лишь поверхностно, о теории. Смысл его выступления не в том, как авторов с книгами связать. Ни одна БД не делается для авторов и книг :) Это просто пример. Вы ещё бочку накатите за то, что у книги нет ISBN, а у автора - LastName ;)
Однако, большинство вопросов касаются не столько темы, затронутой Эриком, сколько вообще OODBMS подхода...
>> Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
Он вообще ничего не предлагает. В данном выступлении. Он даёт математическое обоснование того, что уже существует в разных вариантах много лет. Просто "до него" свойства дуальности подобных вещей, видимо, были не изучены достаточно и не были формализованы. Этим он занимается. И на этой основе уже можно начинать что-то строить, опираться ещё и на доказательства, а не только на опыт. Обобщение, базис.
А базы данных нереляционные существуют давно, ничего нового, да. Вы можете посмотреть на MongoDB, Cassandra, RavenDB... Мало ли. Смотрите, что ОНИ предлагают (в свете вопроса). Давно. Успешно!! Цель выступления Эрика была в том, чтобы показать, что два этих мира - OODBMS и RDBMS не противопоставляются друг другу, не "воюют" друг с другом, а, как инь и янь (его сравнение) дополняют друг друга и могут (и когда-нибудь будут) сосуществовать вместе. Если Вы никогда с подобным не сталкивались - очень рекомендую посмотреть ролик о CoachDB с конференции Norwegian Developers Conference 2010 (NDC2010). Не к тому, что CoachDB самый-самый-самый крутой, круче, даже, чем (о, боже, какое кощунство!) MySQL, а просто расширить кругозор и увидеть, что такие базы существуют давно, что они могут, что не могут, для чего применяются, как работают. Очень неплохой introduction. А покопавшись, Вы увидите, что они ещё и используются достаточно широко. Google, Amazon, Facebook... Это только самые известные... Применений полно. Мы вот, ещё, начнём ;)
Кроме того.. Думаю, я не нарушу NDA (вроде в инете уже инфа есть), сказав, что подобные фичи (пока не совсем ясно в каком объёме, на следующей неделе у нас с ними митинг, может скажут что-то подробнее) будут в Динали. Это который SQL Server 2011. От Microsoft. Уже. Есть. Понимаете? В классической RDBMS. Мир - он движется. Смотрите по сторонам, "майсиквел рулит потому, что там появились процедуры и ещё он кульный а главное - бесплааааатный" (последнее слово произносить с особым блаженством, это ведь основная характеристика сервера баз данных) - это не финальное знание свыше, вокруг ещё столько интересного, разного, другого концептуально! :)
Следующий вопрос туда же ;) (ЖЖ не позволяет написать всё в один коммент)
no subject
alexey raga (from livejournal.com)2010-12-11 02:02 am (UTC)(link)
>> Да, если использовать таблицу связей, куда ее поместить
Да никуда. Зачем Вы вообще приплели сюда "таблицы связей"? Вы реляционную модель пихаете в объектно-ориентированный подход и удивляетесь: Ба! Не подходит! Криво как-то! :) Я уже писал в своём блоге, это как взять гвоздодёр вместо отвётрки и по-детски искренне удивляться, до чего же неудобный инструмент для выкручивания болтов люди догадались придумать :) В объектной модели Вам не потребуются никаке "таблицы связи". Они существуют только потому, что парадигма RDBMS такая. У Вас и в коде нет никаких "коллекций связи", а есть объекты и отношения между ними. Я надеюсь. Если, конечно, Вы тупо не мапите таблицы БД в объекты один в один, что было бы смешно, конечно же и, не волнуйтесь, я Вас в этом не подозреваю :)
Есть объект "Book", у него есть коллекция авторов, есть коллекция оценок. Такой объект. Целый. С таким объектом мы работаем в коде. Такой объект мы берём с книжной полки. Целый, понимаете? И, в идеале... Я думаю, в подавляющем большинстве случаев, мы работаем с целыми объектами (ну, такова парадигма ОО-программирования) и очень хотим, чтобы БД могла "на тебе объект" и "дай-ка мне мой объект". И не задумываться о маппингах. Это мечта. Не "дай-ка мне три объекта, а я буду их связывать по ничего не значащим с точки зрения бизнес-модели ID" :) Сущность. Объект. Целый. Нормальный, а не "нормализованный". Это и быстрее, кстати: достать и дать одну сущность, а не джойнить нормализованое, возвращать денормализованый продукт джойнов, снова нормализовывать в коде в какой-то один объект и, не дай боже, не забыть включить туда ID всех "вложеных" членов, а то ой, кошмар какой настанет когда захотим сделать update :)
Да, для этого придуман ORM.
>> Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
Придуман. И не только он. Но на счёт "плюя" Вы, конечно, загнули. Если на них "честно" плевать, то Вы не сможете сделать update ;) Он на них не плюёт, а бережно хранит. Да, мы (индустрия) изобрели ORM. В некотором роде это костыль, согласитесь? Я в тезисах о выступлении Эрика это отметил: ORM позволяет нам "пофиксить обратно" тот простой объект, который в "сломанном" виде лежит в БД. Частично. Это всё да. Такой вот хак. Неплохой, хороший хак. А другого и нет. Однако, это сильно увеличивает уровень сложности. Привязывает нас к конкретной схеме и уже нельзя сказать "вот у этого кастомера в объекте пяток атрибутов, а у того - тока два". В ODBMS этого даже не надо говорить. Какой есть объект - ну, такой уж и есть, что есть - то и храним. Каждый клиент получит своё. Никаких "миграций данных" и alter table при добавлении новых свойств. Это - удобно. Часто удобно. Иногда - нет. Всему свои задачи. ORM заставляет нас поддерживать XML-портянки маппингов. Хорошо, в последнее время - не обязательно XML, уже как-то что-то можно и атрибутиками в коде задать. Та ещё задача, если вы что-то более-менее сложное делаете. Погуглите термин "impedance mismatch". Мы делаем охрененно много телодвижений для охрененно простой операции - сохранить объект и получить его обратно. Сложных телодвижений. Со сложными генерациями сложных сиквелов. Ещё раз, посмотрите на альтернативы RDBMS, просто, чтобы быть в курсе.
>>тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей.
Вы либо то, что я писал, читали невнимательно, либо издеваетесь надо мной. Именно это я и сказал в первой фразе о проблемах RDBMS - возможность хранить только скаляры. Ваше "всегды используются таблицы связей" имеет смысл только в "критикуемых" в данном случае RDBMS. В OODBMS, я бы сказал, "никогда не используются таблицы связей". Дуально Вашему "всегда" просто ;) Ну поймите Вы - парадигма другая. Вот и всё.
>>Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее.
С последней фразой согласен. Действительно, в не-реляционной модели такие выверты выглядят дико. Компенсируется это тем, что они там не нужны. И Вы не станете там такого делать. Там и других вывертов хватает :)
no subject
alexey raga (from livejournal.com)2010-12-11 02:03 am (UTC)(link)
Коллеги, быть может это мой баг, может я где-то что-то не так описал, но ни Эрик, ни, тем более, я не имели в виду ничего подобного на панацею от всех бед. Уж точно не было ничего похожего на "Выкиньте ваши RDBMS к чертям" :) Просто... RDBMS не безгрешен. Не беспроблемен, хоть мы к нему и привыкли, считая его безальтернативным по умолчанию. Научившись думать как он. Есть там много проблем, для которых существуют костылики-решения, обходные пути, либо прямые, но сложные пути. До Сиднея из Роттердама можно доплыть на судне. И люди так делали. Ничего зазорного. Просто надо запастить временем, провиантом, медикаментами на долгое плавание, взять врача с собой, книжек почитать и т.д. А можно полететь на самолёте. Я летел. Это удобнее! Но лететь из Роттердама в Антверпен - неудобно. Слишком близко. Лучше плыть. Ещё лучше - ехать на машине. Но не в случае, если у Вас тонна-полтора-три-пять-пятьдесят груза. Тогда всё же удобнее плыть. Инструменты бывают разные, понимаете? Для разных задач. Да, существует большой класс задач, где RDBMS - то, что надо, а ODBMS - не пришей кобыле хвост. Однако, существуют задачи и обратные. И их больше, чем вам кажется, на самом деле. И, может быть, ваши задачи - из того же класса. Просто мы так привыкли - если база, то взять RDBMS и начать запихивать туда маловпихуемое, распределять, нормализовывать, собирать обратно, ORMить... Хотя может быть ГОРАЗДО проще решить задачу с использованием какого-нибудь MongoDB. У нас объект "книга" и мы работаем с книгами. В Domain Model, в бизнес-логике мы работаем с книгами. Так на кой же хрен мы рассуждаем о сферических конях в вакууме типа "а ведь могут быть авторы без книг". Бывают ли коты без улыбок? А улыбки без котов? :) Стоп, господа! Мы котами занимаемся! :) Улыбаются - классно, не улыбаются - Кот.Развеселить(); :) Это наша бизнес-модель, мы с ней работаем, это удобно! В паттерны всякие типа MVC/MVP/MVVM вписывается замечательно, опять же.
О, простой пример. Есть некий сайт, который на страничках отображает некую информацию о неких объектах. О людях, скажем. "Человек" - это бизнес-объект. Он сложный, там и адреса, и телефоны, и линки, и интересы, и имейлы, и чего только нет.
Один подход: нормализовать человека, распихать в таблицы адресов (+справочник "тип адреса"), телефонов (+справочник "тип телефона"), линков (+справочник "тип линка") и т.д. и т.п. Вы лучше меня знаете, посмотрите в свои проекты.
Другой подход: создать тип (класс) "пользователь" в любимом языке программирования и работать с ним. Положил объект "пользователь" в базу, вынул объект "пользователь" из базы. Две операции, никаких джойнов, маппингов, ORM-систем, определений "вот щас пользователь обновил вот этот телефон, поэтому мы делаем update в такую-то таблицу", никаких foreign keys, кластерных-некластерных индексов по ним, оптимизации SQL (вообще нет SQL), ругани с DBA по поводу того, что Hibernate сгенерил SQL, который ему не нравится (вообще нет SQL!), etc, etc. Просто "база, дай мне человека" и "база, сохрани человека, я тут его поправил...". Плюс версионность for free (а пойдите-ка сделайте версионность на RDBMS, чтобы можно было глядеть, каким был наш человек три изменения назад? со всеми адресами, телефонами и прочим, конечно), плюс scalability for free и без выкрутасов, плюс ещё что-нибудь - разные DB дают разные функциональности.
Понятное дело, что что-то дают, а чего-то лишают, а для чего-то тоже есть обходные пути и костылики :) Тоже разные аспекты, но мы можем выбрать не из одного типа инструмента, между "гвоздодёр Bosh или гвоздодёр Simens", а между "гвоздодёр и отвёртка", понимаете?
А самое главное - мы концентрируемся на бизнес-логике нашего приложения. На том, что именно оно должно делать с человеком. ЧТО ОНО ДЕЛАЕТ, а не КАК ХРАНИТЬ. Мы больше не пляшем от схемы базы данных. Случалось вам так делать? Сначала схема - потом логика. Хотя по уму-то, мир в обратном порядке работает, согласитесь. Если нам понадобился тип Суперчеловек, мы просто делаем потомка класса, добавляем кучу новых свойств, поведений и нашу бизнес-логику - и всё продолжает работать. Базе всё равно, какого человека сохранять, там все равны, там коммунизм. Это ли не класс задач, которых очень много и которые отлично решаются данным подходом? :)
no subject
alexey raga (from livejournal.com)2010-12-11 02:04 am (UTC)(link)
А мы просто не привыкли. Мы вообще об этом не знаем, особенно те, кто пишет сайтики из трёх страниц :) А вы посмотрите, почитайте, подумайте. Может инструментик-то и полезным окажется, а? ;) Может там, на этих трёх страницах - четыре объекта? И тогда все эти ORM и прочие прелести нормализации - огромный, неоправданный оверхэд? Может только благодаря такому подходу мы работаем не с четырьмя, а с двадцатью объектами? Ну, проще ведь взять магически целый объект, да отобразить его. Кстати, я встречал такой подход - люди делали объект на страницу, его и показываем, его и правим, его и показываем. Он какой угодно сложный может быть, базе всё равно, а разработчику удобно. Зависит, конечно, от задачи сайта, но встречал, и это было оправдано и удобно.
А в больших системах - тут, возможно, окажется полезным то, о чём Эрик говорил: возможность использовать оба подхода одновременно. И это именно то, что он пытался донести - математика говорит нам, что это возможно. Да, сейчас эти "два мира" противопоставлены, противоречины и слабо связаны. Но это недоразумение, пусть будет мир. Он так и сказал "to make peace" :)
Сравнение от меня: лет этак 5-6 назад мы с коллегами сидели на корпоративной кухне, рассуждая о том, что "функциональный" подход программирования видимо, начинает идти в массы. Тогда только начинал. Языки сами существовали не один десяток лет, кстати. Но... И посмотрите, что сейчас: "функциональный" подход везде. Все говорят о монадных вычислениях, continuations, closures, composition (извините, не знаю либо забыл, как по-русски правильно термины). Только ленивый (действительно, очень ленивый и ограниченный программист) в наши дни не пытается изучить принципы функционального программирования. Потому, что это очень полезно. И потому, что принципы эти идут в императивные языки колоннами просто.
Примерно то же самое, начало чего-то большего, сейчас намечается в плане OODBMS. Уже очень много об этом говорят. Уже очень успешно применяют и сочетают. Давайте открывать глаза, коллеги. Пора! :))))
Случайно нашёл тут ваш поток сознания. Ну что тут сказать? - Научитесь, как в ЖЖ правильно оставлять комментарии тому, кому пишете; - Не надо гнуть пальцы, типа охеренно эзотерическое знание про нереляционные БД доступно сугубо особым западным просвещённым людям. У меня длинее. История знания разнообразных фишечек. В 91 году я читал книги 77 года. Так что это вы просвещайтесь и гуглите. - Особенно понравилось использование конструкции "исключающего мы". "Мы не знаем", говорит автор, имея в виду, "это вы, тупые бараны, не знаете, а я то-то просвещён!" "Мы привыкли писать сайты из 3 страниц", пишет автор, торжествуя своей продвинутостью -- ведь его сайт целых 20 страниц! - При этом образцовая БД приводится -- сущность "профиль пользователя". Н-да. - Подобные выступления должны по уму начинаться с того, почему всё-таки деятельность CODASYL завершилась созданием SQL в таком виде, как мы сейчас имеем, а не разнообразных объектных и нереляционных альтернатив. Почему люди 40 лет назад сошли с ума и что они делали не так. - Умиляет наив, что мол реляционные схемы -- это "как хранить", а вот объектные -- это "чистая логика". Умиляет тем, что в своё время адепты RDBMS точно так же рекламировали свои идеи в стиле "это у альтернативщиков заботятся, как хранить, а у нас чистая бизнес-логика" - На вопрос, как организовать связи в случае M-N, так ничего и не сказано. Много шлака про какие-то поездки и пр. "открывание глаз". НА что конкретно -- видимо, надо гуглить. Что именно гуглить, ну сами должны знать, не дети же.
В принципе, можно сказать БД, чтобы требуемые связи между объектами хранились и поддерживались самостоятельно. У объекта будет некий ID с типом скажем "указатель", он не будет выводиться на экран, мы его не будем описывать, простое упоминание связи объектов приведёт к автоматическому выделению полей и таблиц для связей. ОК, полезное дело. Но это вопрос нотации запросов. Не вижу проблем впилить его поддержку в клиентский язык. Как, скажем, MDX и язык Oracle BI server на лету переводятся в SQL.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Но смысл у всей этой функциональной ахинеи есть: так как SQL Server от лидеров отстал, кажется, навсегда, то лучше уж подсадить на функциональщину, чем ждать, когда все просто тихо свалят.
no subject
no subject
Собственно, достаточно разрешить поля-вложенные таблицы и мы то самое и получим. Смех в том, что их эффективная реализация все равно может оказаться обычной реляционной, единственное отличие - что внешне это будет более удобно для использования.
no subject
no subject
По большому счёту несколько раздражает тавтологичность использования
FROM X INNER JOIN Y ON X.ID = Y.PARENT_ID
когда и так других ключей и связей между X и Y нет. Дура база могла бы и сама догадаться. В мускуле есть X JOIN Y on (KEY_ID), и всё равно "on (KEY_ID)" незачем.
В недоумении....
> Таким образом, заявил Эрик, из моего простого объекта получилось вдруг три новых, в которые добавились какие-то новые сущности (идентификаторы), не имеющие к реальному объекту никакого отношения
Вообще-то авторы могут быть общими у разных книг. Более того, могут быть авторы и без книг.
Для отчётов авторов надо как-то идентифицировать. Можно, конечно, по имени в паспорте. Но тогда всё равно надо тягать с этим ID все данные по авторам. Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
> плюс нужно писать дополнительный код, осуществляющий трансформацию
Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
> В результирующем “реляционном” подходе наоборот - потомок всегда знает о том, кто его родитель.
Бред. Авторы и книги -- кто чей предок и потомок? И прекрасно обходятся без прямых ссылок на себя, тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей. И 1:N тоже можно сделать так.
Re: В недоумении....
C 1:N и двумя таблицами все проще.
Re: В недоумении....
(Anonymous) 2010-12-09 12:52 pm (UTC)(link)Раз мы говорим о стрелках, мне кажется неправильным выделять какое-то их направление отдельно, если мы говорим о внешнем представлении, а не о хранении.
Внутри пусть хранят как им самим удобнее, главное - что мы видим снаружи.
no subject
no subject
Вопросов, действительно, достаточно, и Эрик рассказал лишь поверхностно, о теории. Смысл его выступления не в том, как авторов с книгами связать. Ни одна БД не делается для авторов и книг :) Это просто пример. Вы ещё бочку накатите за то, что у книги нет ISBN, а у автора - LastName ;)
Однако, большинство вопросов касаются не столько темы, затронутой Эриком, сколько вообще OODBMS подхода...
>> Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
Он вообще ничего не предлагает. В данном выступлении. Он даёт математическое обоснование того, что уже существует в разных вариантах много лет. Просто "до него" свойства дуальности подобных вещей, видимо, были не изучены достаточно и не были формализованы. Этим он занимается. И на этой основе уже можно начинать что-то строить, опираться ещё и на доказательства, а не только на опыт. Обобщение, базис.
А базы данных нереляционные существуют давно, ничего нового, да. Вы можете посмотреть на MongoDB, Cassandra, RavenDB... Мало ли. Смотрите, что ОНИ предлагают (в свете вопроса). Давно. Успешно!!
Цель выступления Эрика была в том, чтобы показать, что два этих мира - OODBMS и RDBMS не противопоставляются друг другу, не "воюют" друг с другом, а, как инь и янь (его сравнение) дополняют друг друга и могут (и когда-нибудь будут) сосуществовать вместе.
Если Вы никогда с подобным не сталкивались - очень рекомендую посмотреть ролик о CoachDB с конференции Norwegian Developers Conference 2010 (NDC2010). Не к тому, что CoachDB самый-самый-самый крутой, круче, даже, чем (о, боже, какое кощунство!) MySQL, а просто расширить кругозор и увидеть, что такие базы существуют давно, что они могут, что не могут, для чего применяются, как работают. Очень неплохой introduction.
А покопавшись, Вы увидите, что они ещё и используются достаточно широко. Google, Amazon, Facebook... Это только самые известные... Применений полно. Мы вот, ещё, начнём ;)
Кроме того.. Думаю, я не нарушу NDA (вроде в инете уже инфа есть), сказав, что подобные фичи (пока не совсем ясно в каком объёме, на следующей неделе у нас с ними митинг, может скажут что-то подробнее) будут в Динали. Это который SQL Server 2011. От Microsoft. Уже. Есть. Понимаете? В классической RDBMS. Мир - он движется. Смотрите по сторонам, "майсиквел рулит потому, что там появились процедуры и ещё он кульный а главное - бесплааааатный" (последнее слово произносить с особым блаженством, это ведь основная характеристика сервера баз данных) - это не финальное знание свыше, вокруг ещё столько интересного, разного, другого концептуально! :)
Следующий вопрос туда же ;) (ЖЖ не позволяет написать всё в один коммент)
no subject
Да никуда. Зачем Вы вообще приплели сюда "таблицы связей"? Вы реляционную модель пихаете в объектно-ориентированный подход и удивляетесь: Ба! Не подходит! Криво как-то! :)
Я уже писал в своём блоге, это как взять гвоздодёр вместо отвётрки и по-детски искренне удивляться, до чего же неудобный инструмент для выкручивания болтов люди догадались придумать :)
В объектной модели Вам не потребуются никаке "таблицы связи". Они существуют только потому, что парадигма RDBMS такая. У Вас и в коде нет никаких "коллекций связи", а есть объекты и отношения между ними. Я надеюсь. Если, конечно, Вы тупо не мапите таблицы БД в объекты один в один, что было бы смешно, конечно же и, не волнуйтесь, я Вас в этом не подозреваю :)
Есть объект "Book", у него есть коллекция авторов, есть коллекция оценок. Такой объект. Целый. С таким объектом мы работаем в коде. Такой объект мы берём с книжной полки. Целый, понимаете?
И, в идеале... Я думаю, в подавляющем большинстве случаев, мы работаем с целыми объектами (ну, такова парадигма ОО-программирования) и очень хотим, чтобы БД могла "на тебе объект" и "дай-ка мне мой объект". И не задумываться о маппингах. Это мечта. Не "дай-ка мне три объекта, а я буду их связывать по ничего не значащим с точки зрения бизнес-модели ID" :) Сущность. Объект. Целый. Нормальный, а не "нормализованный". Это и быстрее, кстати: достать и дать одну сущность, а не джойнить нормализованое, возвращать денормализованый продукт джойнов, снова нормализовывать в коде в какой-то один объект и, не дай боже, не забыть включить туда ID всех "вложеных" членов, а то ой, кошмар какой настанет когда захотим сделать update :)
Да, для этого придуман ORM.
>> Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
Придуман. И не только он.
Но на счёт "плюя" Вы, конечно, загнули. Если на них "честно" плевать, то Вы не сможете сделать update ;) Он на них не плюёт, а бережно хранит.
Да, мы (индустрия) изобрели ORM. В некотором роде это костыль, согласитесь? Я в тезисах о выступлении Эрика это отметил: ORM позволяет нам "пофиксить обратно" тот простой объект, который в "сломанном" виде лежит в БД. Частично. Это всё да. Такой вот хак. Неплохой, хороший хак. А другого и нет.
Однако, это сильно увеличивает уровень сложности. Привязывает нас к конкретной схеме и уже нельзя сказать "вот у этого кастомера в объекте пяток атрибутов, а у того - тока два". В ODBMS этого даже не надо говорить. Какой есть объект - ну, такой уж и есть, что есть - то и храним. Каждый клиент получит своё. Никаких "миграций данных" и alter table при добавлении новых свойств. Это - удобно. Часто удобно. Иногда - нет. Всему свои задачи.
ORM заставляет нас поддерживать XML-портянки маппингов. Хорошо, в последнее время - не обязательно XML, уже как-то что-то можно и атрибутиками в коде задать. Та ещё задача, если вы что-то более-менее сложное делаете.
Погуглите термин "impedance mismatch".
Мы делаем охрененно много телодвижений для охрененно простой операции - сохранить объект и получить его обратно. Сложных телодвижений. Со сложными генерациями сложных сиквелов.
Ещё раз, посмотрите на альтернативы RDBMS, просто, чтобы быть в курсе.
>>тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей.
Вы либо то, что я писал, читали невнимательно, либо издеваетесь надо мной. Именно это я и сказал в первой фразе о проблемах RDBMS - возможность хранить только скаляры. Ваше "всегды используются таблицы связей" имеет смысл только в "критикуемых" в данном случае RDBMS. В OODBMS, я бы сказал, "никогда не используются таблицы связей". Дуально Вашему "всегда" просто ;)
Ну поймите Вы - парадигма другая. Вот и всё.
>>Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее.
С последней фразой согласен. Действительно, в не-реляционной модели такие выверты выглядят дико. Компенсируется это тем, что они там не нужны. И Вы не станете там такого делать. Там и других вывертов хватает :)
no subject
Просто... RDBMS не безгрешен. Не беспроблемен, хоть мы к нему и привыкли, считая его безальтернативным по умолчанию. Научившись думать как он.
Есть там много проблем, для которых существуют костылики-решения, обходные пути, либо прямые, но сложные пути.
До Сиднея из Роттердама можно доплыть на судне. И люди так делали. Ничего зазорного. Просто надо запастить временем, провиантом, медикаментами на долгое плавание, взять врача с собой, книжек почитать и т.д. А можно полететь на самолёте. Я летел. Это удобнее! Но лететь из Роттердама в Антверпен - неудобно. Слишком близко. Лучше плыть. Ещё лучше - ехать на машине. Но не в случае, если у Вас тонна-полтора-три-пять-пятьдесят груза. Тогда всё же удобнее плыть.
Инструменты бывают разные, понимаете? Для разных задач. Да, существует большой класс задач, где RDBMS - то, что надо, а ODBMS - не пришей кобыле хвост.
Однако, существуют задачи и обратные. И их больше, чем вам кажется, на самом деле. И, может быть, ваши задачи - из того же класса. Просто мы так привыкли - если база, то взять RDBMS и начать запихивать туда маловпихуемое, распределять, нормализовывать, собирать обратно, ORMить... Хотя может быть ГОРАЗДО проще решить задачу с использованием какого-нибудь MongoDB.
У нас объект "книга" и мы работаем с книгами. В Domain Model, в бизнес-логике мы работаем с книгами. Так на кой же хрен мы рассуждаем о сферических конях в вакууме типа "а ведь могут быть авторы без книг". Бывают ли коты без улыбок? А улыбки без котов? :) Стоп, господа! Мы котами занимаемся! :) Улыбаются - классно, не улыбаются - Кот.Развеселить(); :)
Это наша бизнес-модель, мы с ней работаем, это удобно! В паттерны всякие типа MVC/MVP/MVVM вписывается замечательно, опять же.
О, простой пример. Есть некий сайт, который на страничках отображает некую информацию о неких объектах. О людях, скажем. "Человек" - это бизнес-объект. Он сложный, там и адреса, и телефоны, и линки, и интересы, и имейлы, и чего только нет.
Один подход: нормализовать человека, распихать в таблицы адресов (+справочник "тип адреса"), телефонов (+справочник "тип телефона"), линков (+справочник "тип линка") и т.д. и т.п. Вы лучше меня знаете, посмотрите в свои проекты.
Другой подход: создать тип (класс) "пользователь" в любимом языке программирования и работать с ним. Положил объект "пользователь" в базу, вынул объект "пользователь" из базы. Две операции, никаких джойнов, маппингов, ORM-систем, определений "вот щас пользователь обновил вот этот телефон, поэтому мы делаем update в такую-то таблицу", никаких foreign keys, кластерных-некластерных индексов по ним, оптимизации SQL (вообще нет SQL), ругани с DBA по поводу того, что Hibernate сгенерил SQL, который ему не нравится (вообще нет SQL!), etc, etc.
Просто "база, дай мне человека" и "база, сохрани человека, я тут его поправил...".
Плюс версионность for free (а пойдите-ка сделайте версионность на RDBMS, чтобы можно было глядеть, каким был наш человек три изменения назад? со всеми адресами, телефонами и прочим, конечно), плюс scalability for free и без выкрутасов, плюс ещё что-нибудь - разные DB дают разные функциональности.
Понятное дело, что что-то дают, а чего-то лишают, а для чего-то тоже есть обходные пути и костылики :) Тоже разные аспекты, но мы можем выбрать не из одного типа инструмента, между "гвоздодёр Bosh или гвоздодёр Simens", а между "гвоздодёр и отвёртка", понимаете?
А самое главное - мы концентрируемся на бизнес-логике нашего приложения. На том, что именно оно должно делать с человеком. ЧТО ОНО ДЕЛАЕТ, а не КАК ХРАНИТЬ. Мы больше не пляшем от схемы базы данных. Случалось вам так делать? Сначала схема - потом логика. Хотя по уму-то, мир в обратном порядке работает, согласитесь.
Если нам понадобился тип Суперчеловек, мы просто делаем потомка класса, добавляем кучу новых свойств, поведений и нашу бизнес-логику - и всё продолжает работать. Базе всё равно, какого человека сохранять, там все равны, там коммунизм.
Это ли не класс задач, которых очень много и которые отлично решаются данным подходом? :)
no subject
Ну, проще ведь взять магически целый объект, да отобразить его. Кстати, я встречал такой подход - люди делали объект на страницу, его и показываем, его и правим, его и показываем. Он какой угодно сложный может быть, базе всё равно, а разработчику удобно.
Зависит, конечно, от задачи сайта, но встречал, и это было оправдано и удобно.
А в больших системах - тут, возможно, окажется полезным то, о чём Эрик говорил: возможность использовать оба подхода одновременно. И это именно то, что он пытался донести - математика говорит нам, что это возможно. Да, сейчас эти "два мира" противопоставлены, противоречины и слабо связаны. Но это недоразумение, пусть будет мир. Он так и сказал "to make peace" :)
Сравнение от меня: лет этак 5-6 назад мы с коллегами сидели на корпоративной кухне, рассуждая о том, что "функциональный" подход программирования видимо, начинает идти в массы. Тогда только начинал. Языки сами существовали не один десяток лет, кстати. Но...
И посмотрите, что сейчас: "функциональный" подход везде. Все говорят о монадных вычислениях, continuations, closures, composition (извините, не знаю либо забыл, как по-русски правильно термины). Только ленивый (действительно, очень ленивый и ограниченный программист) в наши дни не пытается изучить принципы функционального программирования. Потому, что это очень полезно. И потому, что принципы эти идут в императивные языки колоннами просто.
Примерно то же самое, начало чего-то большего, сейчас намечается в плане OODBMS. Уже очень много об этом говорят. Уже очень успешно применяют и сочетают. Давайте открывать глаза, коллеги.
Пора! :))))
no subject
- Научитесь, как в ЖЖ правильно оставлять комментарии тому, кому пишете;
- Не надо гнуть пальцы, типа охеренно эзотерическое знание про нереляционные БД доступно сугубо особым западным просвещённым людям. У меня длинее. История знания разнообразных фишечек. В 91 году я читал книги 77 года. Так что это вы просвещайтесь и гуглите.
- Особенно понравилось использование конструкции "исключающего мы". "Мы не знаем", говорит автор, имея в виду, "это вы, тупые бараны, не знаете, а я то-то просвещён!" "Мы привыкли писать сайты из 3 страниц", пишет автор, торжествуя своей продвинутостью -- ведь его сайт целых 20 страниц!
- При этом образцовая БД приводится -- сущность "профиль пользователя". Н-да.
- Подобные выступления должны по уму начинаться с того, почему всё-таки деятельность CODASYL завершилась созданием SQL в таком виде, как мы сейчас имеем, а не разнообразных объектных и нереляционных альтернатив. Почему люди 40 лет назад сошли с ума и что они делали не так.
- Умиляет наив, что мол реляционные схемы -- это "как хранить", а вот объектные -- это "чистая логика". Умиляет тем, что в своё время адепты RDBMS точно так же рекламировали свои идеи в стиле "это у альтернативщиков заботятся, как хранить, а у нас чистая бизнес-логика"
- На вопрос, как организовать связи в случае M-N, так ничего и не сказано. Много шлака про какие-то поездки и пр. "открывание глаз". НА что конкретно -- видимо, надо гуглить. Что именно гуглить, ну сами должны знать, не дети же.
В принципе, можно сказать БД, чтобы требуемые связи между объектами хранились и поддерживались самостоятельно. У объекта будет некий ID с типом скажем "указатель", он не будет выводиться на экран, мы его не будем описывать, простое упоминание связи объектов приведёт к автоматическому выделению полей и таблиц для связей. ОК, полезное дело. Но это вопрос нотации запросов. Не вижу проблем впилить его поддержку в клиентский язык. Как, скажем, MDX и язык Oracle BI server на лету переводятся в SQL.