Ошибки надо исправлять. Разлив интересного это только предлог засучить рукава и поработать. Всем нам встречно к ведомству. А переход с КЛАДРа на ФИАС — это прогресс, я считаю.
Втащить то можно всё что угодно. Вопрос с чем это передадим дальше? Насколько легко будет сопровождать? Развивать вверх по уровням?
Так то и в ассемблере с прямым доступом в диск можно. Будет даже быстро. Толко долго и дорого.
Я люблю таблички, но это всё ассемблер для данных. Мы уже в другом веке живём.
Ошибки надо исправлять. Разлив интересного это только предлог засучить рукава и поработать. Всем нам встречно к ведомству. А переход с КЛАДРа на ФИАС — это прогресс, я считаю.
Втащить то можно всё что угодно. Вопрос с чем это передадим дальше? Насколько легко будет сопровождать? Развивать вверх по уровням?
Так то и в ассемблере с прямым доступом в диск можно. Будет даже быстро. Толко долго и дорого.
Я люблю таблички, но это всё ассемблер для данных. Мы уже в другом веке живём.
Картиночки сравнительные появились про производительность ядерных архитектур в CoreMark на МГц. BOOM и Rocket — это RISC-V ядра (вдруг кто не знает :). У Интеловского Atom N455 примерно 2,7 CoreMark/МГц.
Сюда же, для сравнения: Western Digital выпускает в этом 2019 году свой первый RISC-V процессор SweRV по 28 нм технологии с производительностью на 1,8 ГГц в 4.9 CoreMark/МГц Планируемый тираж – до 1 млрд/год.
Это верно. Как и то, что бывает шиворот навырот: «Возможность запуска в x86-окружении приложений, созданных для платформы ARM, через применение специальной прослойки»
Во-первых, маркетологи Интел молчат про исправление дыр в своих ядрах х86. Скорее всего это значит, что ядра неисправленные.
Во-вторых, мне RISC-V гораздо интереснее развивать, чем х86. Уже понятно куда мир движется. Это подрывная технология. ARM и MIPS уже пасуют перед этой угрозой безмятежному миру проприетарных ISA :)
В-третьих, у Интела готова реализация самых современных интерфейсов. В доступных IP-ядрах для RISC-V это не скоро появится.
В-четвёртых, аппаратное исполнение х86 всегда быстрее программной эмуляции.
Если цена не подкачает, отличный современный 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.
Именно так и написал. Хотите целостности — получите хоть в объектном, хоть в реляционном виде. Нет такой потребности — на здоровье.
Втащить то можно всё что угодно. Вопрос с чем это передадим дальше? Насколько легко будет сопровождать? Развивать вверх по уровням?
Так то и в ассемблере с прямым доступом в диск можно. Будет даже быстро. Толко долго и дорого.
Я люблю таблички, но это всё ассемблер для данных. Мы уже в другом веке живём.
Ошибки надо исправлять. Разлив интересного это только предлог засучить рукава и поработать. Всем нам встречно к ведомству. А переход с КЛАДРа на ФИАС — это прогресс, я считаю.
Втащить то можно всё что угодно. Вопрос с чем это передадим дальше? Насколько легко будет сопровождать? Развивать вверх по уровням?
Так то и в ассемблере с прямым доступом в диск можно. Будет даже быстро. Толко долго и дорого.
Я люблю таблички, но это всё ассемблер для данных. Мы уже в другом веке живём.
Про ошибки написал прямо по тексту статьи. И оставил как спецзадачку для внимательных))
Мучаются-то как раз с DBF и прочими SQL-образными. XML — прекрасен!
Хотя, честно признать, в наших проектах пока что используем DBF ;)
Картиночки сравнительные появились про производительность ядерных архитектур в CoreMark на МГц. BOOM и Rocket — это RISC-V ядра (вдруг кто не знает :). У Интеловского Atom N455 примерно 2,7 CoreMark/МГц.
Сюда же, для сравнения: Western Digital выпускает в этом 2019 году свой первый RISC-V процессор SweRV по 28 нм технологии с производительностью на 1,8 ГГц в 4.9 CoreMark/МГц Планируемый тираж – до 1 млрд/год.
Во-вторых, мне RISC-V гораздо интереснее развивать, чем х86. Уже понятно куда мир движется. Это подрывная технология. ARM и MIPS уже пасуют перед этой угрозой безмятежному миру проприетарных ISA :)
В-третьих, у Интела готова реализация самых современных интерфейсов. В доступных IP-ядрах для RISC-V это не скоро появится.
В-четвёртых, аппаратное исполнение х86 всегда быстрее программной эмуляции.
На же не суперкалькулятор нужен, в экзокортекс. Правильно?)
А дальше? В первом приближении разница в именовании. Объект оживает сам. А в $user->login = 'TestUser' что-то странное. У меня по объектно-православному att.new(«Аким»). Но после вопроса уверенность пропала))
Сегодня всё сильно другое. Если включить свежий незамутненный прошлым взгляд, а себя переступить/обновить очень боязно, наверное, то можно увидеть прогресс. Я, например люблю среду Оберона, но обжёгся на Дельфи. С++ меня долго ломал и, наверное к нему не вернусь. А у сегодняшнего Каше, по сравнению даже с тем что было 7-10 лет назад, резкий прогресс. И любовь его настоящих разработчиков, как бы пафосно это не звучало. Я вот и решил разобраться сам, отчего такие полярные мнения.
Пока вывод такой, кто не работал вплотную с Caché последние 5 лет, ничего по делу сказать не могут. А резкий рост новых разработчиков и успех на рынке говорят сами за себя.
Чуть выше Михаил michael_vostrikov устроил мне вполне качественный детальный допрос/разнос с примерами живого кода. :)
никакого смысла возвращаться в 90е с такой технологией нет.
подставь свой вариант :)
Обманное впечатление :) Верно другое – разбираюсь в теме. ObjectScript для меня новый язык.
Я говорю о разнице между манипуляцией данными и общением объектов между собой. Как хранятся данные физически — это из другой оперы.
То есть self.att.run_obj_method("%DeleteId", [id]) читаем как «эй дружок тебя не взяли в космонавты». И он что-то там делает по самоудалению из хранилища. Может метку поставит "«здесь был Вася» или «отправит сообщение другому объекту — регистратору несостоявшихся космонавтов: внеси меня в свой список». Это уже неважно. Структуры данных так не делают – они же записи в таблице, а не объекты.
Прикрываясь «строгой математической основой», необходимо её использовать. А что-то примеров строго соответствия реляционной модели по Кодду среди РСУБД не видно. Как-то все своими «граблями» обходятся.
Я говорю о сравнении «мёртвых данных» в таблицах с живыми объектами в программах. И хочется про это поговорить.
Именно так и написал. Хотите целостности — получите хоть в объектном, хоть в реляционном виде. Нет такой потребности — на здоровье.