ссылко: "Я открыл гугл и набрал слова “математика развернуть стрелочки”. Ба! Википедия! Теория категорий и ко-алгебра! Теперь я точно знаю, что есть решение проблемы!"
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
Ну, проще ведь взять магически целый объект, да отобразить его. Кстати, я встречал такой подход - люди делали объект на страницу, его и показываем, его и правим, его и показываем. Он какой угодно сложный может быть, базе всё равно, а разработчику удобно.
Зависит, конечно, от задачи сайта, но встречал, и это было оправдано и удобно.
А в больших системах - тут, возможно, окажется полезным то, о чём Эрик говорил: возможность использовать оба подхода одновременно. И это именно то, что он пытался донести - математика говорит нам, что это возможно. Да, сейчас эти "два мира" противопоставлены, противоречины и слабо связаны. Но это недоразумение, пусть будет мир. Он так и сказал "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.