Если цена не подкачает, отличный современный Wi-Fi + Thunderbolt + Display микроконтролер получится. Cтавим в комплект к полноценному RISC-V процессору и резервному ПЛИС (на развитие). Чудесный перспективный компьютер получится. Да ещё и с возможностью запускать легаси х86 программы ;)
Так очень хорошие вопросы получились. У меня есть ответы, но я в них засомневался и появились новые. Например, где граница между просто данными и уже объектами? Вроде бы просто – у объектов есть собственное поведение, а у данных нет. В реляционной модели есть только данные и нет объектов. Это граница между процедурным и объектными подходами. То есть любой ORM ликвидирует объект, превращая его в набор данных. И ActiveRecord не исключение.
А дальше? В первом приближении разница в именовании. Объект оживает сам. А в $user->login = 'TestUser' что-то странное. У меня по объектно-православному att.new(«Аким»). Но после вопроса уверенность пропала))
Что тут сказать, сочувствую((
Сегодня всё сильно другое. Если включить свежий незамутненный прошлым взгляд, а себя переступить/обновить очень боязно, наверное, то можно увидеть прогресс. Я, например люблю среду Оберона, но обжёгся на Дельфи. С++ меня долго ломал и, наверное к нему не вернусь. А у сегодняшнего Каше, по сравнению даже с тем что было 7-10 лет назад, резкий прогресс. И любовь его настоящих разработчиков, как бы пафосно это не звучало. Я вот и решил разобраться сам, отчего такие полярные мнения.
Пока вывод такой, кто не работал вплотную с Caché последние 5 лет, ничего по делу сказать не могут. А резкий рост новых разработчиков и успех на рынке говорят сами за себя.
А если серьёзно, напишите в чём ваш профессиональный взгляд видит примеры «недостатков», как с монстрами РСУБД типа Оракл/Микрософт, так и новичками, типа Апачевских HBase/Kudu или вполне отечественных ClickHouse и Postres Pro?
Чуть выше Михаил michael_vostrikov устроил мне вполне качественный детальный допрос/разнос с примерами живого кода. :)
oracle/microsoft/ibm вобрал в себя все недостатки реляционных субд (Кодд аж возмущался по этому поводу и уволился из ibm), поэтому проиграл ещё в 90-х. врядил в наше время можно найти проект на oracle/microsoft/ibm не из 90х (ibm с горяча запилила noSQL lotus/domino и расстроившись сбросила его на индийцев)
никакого смысла возвращаться в 90е с такой технологией нет.
подставь свой вариант :)
То что за 40 лет могла не меняться модель данных, вполне поверю. Есть такие динозавры. Но это очень редкие особые случаи. Там и компьютеры могли не меняться с тех пор.
Согласен, наверное стоило добавить ещё пример. Решил не перегружать. Про связывание и целостность хранимых объектов в документации Defining and Using Relationships
Обманное впечатление :) Верно другое – разбираюсь в теме. ObjectScript для меня новый язык.
Так в примере про целостность ничего не сказано. Вы спрашиваете о том, чего нет в статье. В комментариях выше написал какие есть варианты развития событий.
Что-то не едут мои лыжи))
Я говорю о разнице между манипуляцией данными и общением объектов между собой. Как хранятся данные физически — это из другой оперы.
То есть self.att.run_obj_method("%DeleteId", [id]) читаем как «эй дружок тебя не взяли в космонавты». И он что-то там делает по самоудалению из хранилища. Может метку поставит "«здесь был Вася» или «отправит сообщение другому объекту — регистратору несостоявшихся космонавтов: внеси меня в свой список». Это уже неважно. Структуры данных так не делают – они же записи в таблице, а не объекты.
Продолжу эту мысль. Некоторые 40 лет работают с Паскалем и Фортраном в категориях процедурного программирования, которое имеет строгие математические основы. И в состоянии описать любые данные ;)
Прикрываясь «строгой математической основой», необходимо её использовать. А что-то примеров строго соответствия реляционной модели по Кодду среди РСУБД не видно. Как-то все своими «граблями» обходятся.
Я говорю о сравнении «мёртвых данных» в таблицах с живыми объектами в программах. И хочется про это поговорить.
Реляционные базы выбирают в том числе и из-за контроля целостности данных. Даже если не поставить внешние ключи для промежуточной таблицы attendee-event (что иногда делают по техническим причинам), база все равно не даст создать запись без указания attendee_id или event_id.
Именно так и написал. Хотите целостности — получите хоть в объектном, хоть в реляционном виде. Нет такой потребности — на здоровье.
att.run_obj_method('какая-то строка') — «какая-то строка» это и есть магическая константа. С точки зрения языка это константы, а на самом деле запускают разную логику.
По мне странно называть всё 'что в кавычках' константами. Обоснуете?
Там это точно так же спрятано за специальным языком.
ActiveRecord работает с объектами языка программирования, с обычным ООП. В моем примере User это класс, как и в вашем.
Это про одно и тоже. Поэтому будем есть этого слона по частям.
ActiveRecord основан на соглашениях и специальном языке. Он вводит свой DSL. Как минимум для миграций это нужно.
Примеров объектов на ActiveRecord, окромя кортежей, не обнаруживаю. Скажите где посмотреть?
Отличается. Если я правильно пониманию, ActiveRecord работает только с кортежами.
Магических констант что-то не припомню :) Два языка и привязки между ними. При использовании только ObjectScript всё ещё проще.
В чем это выражается? В коде примеров нет никаких отличий от кода с SQL ORM.
Сознательно отказался от примеров с SQL. Если интересно, посмотрите примеры в большом обзоре про глобалы 1, 2, 3.
Если будет много вопросов, подумаю над дополнительным материалом для публикации.
Как и всё мейнстимовые СУБД — разновидность B-деревьев. Только не прячет этот факт за фасадом SQL, а активно использует на благо разработчиков.
Чем это отличается от ORM? Я бы даже сказал, чем это отличается от ActiveRecord?
Фасадом. Фактически ORM отсутствует для разработчика приложения. Я люблю Ruby, но это было так давно… А сегодня только так.
Список участников хранится в самом объекте Event? Как получить информацию, в каких мероприятиях участвует участник?
Участников этого мероприятия — да, в Event. Ссылкой на Attendee. Этот кусочек кода для примера и взят приложения, где один и то же участник посещает разные Event. Этой части в примерах нет, а там объект-участник знает в каких он мероприятиях участвовал. А внутри Event может быть в разных ролях: слушателем, докладчиком и комментатором.
На же не суперкалькулятор нужен, в экзокортекс. Правильно?)
А дальше? В первом приближении разница в именовании. Объект оживает сам. А в $user->login = 'TestUser' что-то странное. У меня по объектно-православному att.new(«Аким»). Но после вопроса уверенность пропала))
Сегодня всё сильно другое. Если включить свежий незамутненный прошлым взгляд, а себя переступить/обновить очень боязно, наверное, то можно увидеть прогресс. Я, например люблю среду Оберона, но обжёгся на Дельфи. С++ меня долго ломал и, наверное к нему не вернусь. А у сегодняшнего Каше, по сравнению даже с тем что было 7-10 лет назад, резкий прогресс. И любовь его настоящих разработчиков, как бы пафосно это не звучало. Я вот и решил разобраться сам, отчего такие полярные мнения.
Пока вывод такой, кто не работал вплотную с Caché последние 5 лет, ничего по делу сказать не могут. А резкий рост новых разработчиков и успех на рынке говорят сами за себя.
Чуть выше Михаил michael_vostrikov устроил мне вполне качественный детальный допрос/разнос с примерами живого кода. :)
никакого смысла возвращаться в 90е с такой технологией нет.
подставь свой вариант :)
Обманное впечатление :) Верно другое – разбираюсь в теме. ObjectScript для меня новый язык.
Я говорю о разнице между манипуляцией данными и общением объектов между собой. Как хранятся данные физически — это из другой оперы.
То есть self.att.run_obj_method("%DeleteId", [id]) читаем как «эй дружок тебя не взяли в космонавты». И он что-то там делает по самоудалению из хранилища. Может метку поставит "«здесь был Вася» или «отправит сообщение другому объекту — регистратору несостоявшихся космонавтов: внеси меня в свой список». Это уже неважно. Структуры данных так не делают – они же записи в таблице, а не объекты.
Прикрываясь «строгой математической основой», необходимо её использовать. А что-то примеров строго соответствия реляционной модели по Кодду среди РСУБД не видно. Как-то все своими «граблями» обходятся.
Я говорю о сравнении «мёртвых данных» в таблицах с живыми объектами в программах. И хочется про это поговорить.
Именно так и написал. Хотите целостности — получите хоть в объектном, хоть в реляционном виде. Нет такой потребности — на здоровье.
По мне странно называть всё 'что в кавычках' константами. Обоснуете?
Это про одно и тоже. Поэтому будем есть этого слона по частям.
ActiveRecord основан на соглашениях и специальном языке. Он вводит свой DSL. Как минимум для миграций это нужно.
Примеров объектов на ActiveRecord, окромя кортежей, не обнаруживаю. Скажите где посмотреть?
Да, два разных «массива» (это не массивы). Дальше как разработчику заблагорассудится. У меня зависимые объекты (в примере этой части нет).
И спасибо за вопросы! Хорошая мне тренировка для изучения новых тем и хабр-разметки :)
Отличается. Если я правильно пониманию, ActiveRecord работает только с кортежами.
Магических констант что-то не припомню :) Два языка и привязки между ними. При использовании только ObjectScript всё ещё проще.
Сознательно отказался от примеров с SQL. Если интересно, посмотрите примеры в большом обзоре про глобалы 1, 2, 3.
Если будет много вопросов, подумаю над дополнительным материалом для публикации.
Как и всё мейнстимовые СУБД — разновидность B-деревьев. Только не прячет этот факт за фасадом SQL, а активно использует на благо разработчиков.
Фасадом. Фактически ORM отсутствует для разработчика приложения. Я люблю Ruby, но это было так давно… А сегодня только так.
Участников этого мероприятия — да, в Event. Ссылкой на Attendee. Этот кусочек кода для примера и взят приложения, где один и то же участник посещает разные Event. Этой части в примерах нет, а там объект-участник знает в каких он мероприятиях участвовал. А внутри Event может быть в разных ролях: слушателем, докладчиком и комментатором.