Случайно нашёл тут ваш поток сознания. Ну что тут сказать? - Научитесь, как в ЖЖ правильно оставлять комментарии тому, кому пишете; - Не надо гнуть пальцы, типа охеренно эзотерическое знание про нереляционные БД доступно сугубо особым западным просвещённым людям. У меня длинее. История знания разнообразных фишечек. В 91 году я читал книги 77 года. Так что это вы просвещайтесь и гуглите. - Особенно понравилось использование конструкции "исключающего мы". "Мы не знаем", говорит автор, имея в виду, "это вы, тупые бараны, не знаете, а я то-то просвещён!" "Мы привыкли писать сайты из 3 страниц", пишет автор, торжествуя своей продвинутостью -- ведь его сайт целых 20 страниц! - При этом образцовая БД приводится -- сущность "профиль пользователя". Н-да. - Подобные выступления должны по уму начинаться с того, почему всё-таки деятельность CODASYL завершилась созданием SQL в таком виде, как мы сейчас имеем, а не разнообразных объектных и нереляционных альтернатив. Почему люди 40 лет назад сошли с ума и что они делали не так. - Умиляет наив, что мол реляционные схемы -- это "как хранить", а вот объектные -- это "чистая логика". Умиляет тем, что в своё время адепты RDBMS точно так же рекламировали свои идеи в стиле "это у альтернативщиков заботятся, как хранить, а у нас чистая бизнес-логика" - На вопрос, как организовать связи в случае M-N, так ничего и не сказано. Много шлака про какие-то поездки и пр. "открывание глаз". НА что конкретно -- видимо, надо гуглить. Что именно гуглить, ну сами должны знать, не дети же.
В принципе, можно сказать БД, чтобы требуемые связи между объектами хранились и поддерживались самостоятельно. У объекта будет некий ID с типом скажем "указатель", он не будет выводиться на экран, мы его не будем описывать, простое упоминание связи объектов приведёт к автоматическому выделению полей и таблиц для связей. ОК, полезное дело. Но это вопрос нотации запросов. Не вижу проблем впилить его поддержку в клиентский язык. Как, скажем, MDX и язык Oracle BI server на лету переводятся в SQL.
no subject
- Научитесь, как в ЖЖ правильно оставлять комментарии тому, кому пишете;
- Не надо гнуть пальцы, типа охеренно эзотерическое знание про нереляционные БД доступно сугубо особым западным просвещённым людям. У меня длинее. История знания разнообразных фишечек. В 91 году я читал книги 77 года. Так что это вы просвещайтесь и гуглите.
- Особенно понравилось использование конструкции "исключающего мы". "Мы не знаем", говорит автор, имея в виду, "это вы, тупые бараны, не знаете, а я то-то просвещён!" "Мы привыкли писать сайты из 3 страниц", пишет автор, торжествуя своей продвинутостью -- ведь его сайт целых 20 страниц!
- При этом образцовая БД приводится -- сущность "профиль пользователя". Н-да.
- Подобные выступления должны по уму начинаться с того, почему всё-таки деятельность CODASYL завершилась созданием SQL в таком виде, как мы сейчас имеем, а не разнообразных объектных и нереляционных альтернатив. Почему люди 40 лет назад сошли с ума и что они делали не так.
- Умиляет наив, что мол реляционные схемы -- это "как хранить", а вот объектные -- это "чистая логика". Умиляет тем, что в своё время адепты RDBMS точно так же рекламировали свои идеи в стиле "это у альтернативщиков заботятся, как хранить, а у нас чистая бизнес-логика"
- На вопрос, как организовать связи в случае M-N, так ничего и не сказано. Много шлака про какие-то поездки и пр. "открывание глаз". НА что конкретно -- видимо, надо гуглить. Что именно гуглить, ну сами должны знать, не дети же.
В принципе, можно сказать БД, чтобы требуемые связи между объектами хранились и поддерживались самостоятельно. У объекта будет некий ID с типом скажем "указатель", он не будет выводиться на экран, мы его не будем описывать, простое упоминание связи объектов приведёт к автоматическому выделению полей и таблиц для связей. ОК, полезное дело. Но это вопрос нотации запросов. Не вижу проблем впилить его поддержку в клиентский язык. Как, скажем, MDX и язык Oracle BI server на лету переводятся в SQL.