Успешно решал подобную проблему у клиента еще на версии 2005. Они вовремя спохватились, не имея в штате специалистов по СУБД и сделав нагрузочные тесты на ранней стадии. Усеченный пример есть в книжке (в профиле).
именно, что «как бы выполнены». Проблема иерархической модели (к коим относится документ-ориентированная) в необходимости дублирования данных в иерархиях. Или хранить логические ссылки (по коду, ID и т.п.) на другие иерархии с неизбежными соединениями в запросах.
Простейший пример, две иерархии (коллекции в терминах монги) заказов и отгрузок хранят данные о клиентах. Либо дублирование, либо третья иерархия клиентов со ссылками. «Нормализация» в рамках иерархической модели. Привет из 1960-х и от IBM IMS персонально :)
JSON как был легким форматом для сериализации обьектов, так по сути им и остался. Понадобится обеспечение целостности, валидация — пиши код в приложении, языки запросов специфичны для СУБД, стандарты фактически отсутствуют, RFC — предел мечтаний.
XML изначально проектировался для хранения документов, обеспечения целостности и извлечения информации по запросам, стандарт устоялся и щироко используется в корпоративном софтостроении.
Сходство в том, что обе модели основаны на теоретико-графовой иеррхической модели. Но ограничения иерархий тоже известны с 1960-х годов, когда переходили к сетевым и множественным моделям данных.
Более подробно есть в статье "Classification of data models in DBMS" на researchgate и в книжке "СУБД для программиста" (пардон за продакт-плейсмент)
Дополнения по Microsoft SQL Server:
— основная реализация документ-ориентированной модели не JSON, а XML (с версии 2005): нативное хранение, индексация, язык запросов XQuery, поддержка XSD-схем документов. JSON действительно введен в версии 2016 скорее для промежуточного хранения и удобства;
— поддерживается не указанная в сравнительном списке модель «ключ-значение» на основе механизма хеш-таблиц в памяти;
— поддерживается (тoже не указана) многомерная модель — гиперкубы (SQL Server Analysis Services), была еще до версии 2005 под названием MS OLAP.
Несколько пугающая ситуация «сохраним, а вдруг пригодится». Био-организмы выживают на противоположном принципе «отфильтрую, чтобы не мешало». Негенерировать петабайты с рецепторов даже одного человека не проблема.
Видимо после переработки «основополагающих факторов для классификации» модульные тесты стали самыми дешевыми. У экономистов такое часто бывает, кстати.
Тестирование компонента с mock-ами — это типовой модульный тест.
Итеграционный тест «черного яшика» — это что-то из области «сварю суп, бросив в кастрюлю не глядя все с верхней полки холодильника».
Спасибо еще раз, но давайте все же завершим беседу :)
Начните чтение с классики, с Майерса «Надежность программного обеспечения».
Далее переходим к SWEBOK (SoftWare Engineering Base Of Knowlege), где уровни тестирования и примерное число требований/тестов приводятся в виде матрицы. Для модульных речь идет о тысячах, вышестоящие уровни — сотни.
Основное отличие интеграционных тестов от функциональных — whitebox vs blackbox.
Все наоборот, модульные тесты самые дорогие. В системе несколько уровней API, при изменении реализации уровня и рефакторинге приходится перелопачивать все соответствующие модульные тесты. Тогда как тесты API (функциональные-интеграционные) меняются минимально.
Соотношение кода тестов к тестируемому также максимально для модульных, минимум где-то 2:1. Для API уровня 1:10.
Необязательно Linkedin, рекрутеры напрямую по телефону любят звонить. Вопрос в том, что на «интересное предложение» примерно 20-30 кандидатов после скрининга CV и первичного телефонного разговора.
Если претендовать на среднюю и ниже зарплату, то открытых источников, наверное, хватит. Однако я неприятно удивлен, что приведенная в статье цифра для Питера в 2019 году ниже той, что была у меня 15 лет назад. И слабо представляю, как можно жить на указанную цифру в Москве, не имея своего жилья.
Забыли главный пункт :) Расширять круг знакомств и связей. В наших краях около 70% вакансий заполняются «своими», не думаю, что в России ситуация принципиально иная.
Таблица Employees. Получить список сотрудников менеджеры которых устроились на работу в январе месяце любого года и длинна job_title этих сотрудников больше 15ти символов
Не лучше ли требовать со студентов решение с JOIN-ами вместо подзапросов, приучать к хорошему стилю?
Правильно ли я понимаю, термин «озеро данных» (data lake) понадобился для обозначения хранилища, куда информация сливается по принципу «а вдруг понадобится», в отличие от «склада данных» (data warehouse), который проектируют под конкретные нужды?
Нет. Наверху топа-10 поломок во Франции:
— система зажигания
— система торможения
— распределение и КП
1 и 3 отпадают, 2 более долговечно в электрокаре.
Данные исследования Национального Института Потрбления
Цена зависит не от спроса, а от баланса спроса и предложения. Рынок автомобилей высококонкурентный и основан на массовом производстве, средняя маржа производителей около 7%. Себестоимость производства электрокаров существенно ниже, сейчас затык в батарейке.
Я пишу про то, что внутреннее устройство и в частности механика машин с ДВС гораздо сложнее. Это, кстати, одна из причин сопротивления: количество автомастерских и магазинов запчастей уменьшится в разы. Со временем все встанет на свои места, электрокары начального уровня буду стоить не 23К, а не более 10К, также увеличится рынок их аренды.
именно, что «как бы выполнены». Проблема иерархической модели (к коим относится документ-ориентированная) в необходимости дублирования данных в иерархиях. Или хранить логические ссылки (по коду, ID и т.п.) на другие иерархии с неизбежными соединениями в запросах.
Простейший пример, две иерархии (коллекции в терминах монги) заказов и отгрузок хранят данные о клиентах. Либо дублирование, либо третья иерархия клиентов со ссылками. «Нормализация» в рамках иерархической модели. Привет из 1960-х и от IBM IMS персонально :)
XML изначально проектировался для хранения документов, обеспечения целостности и извлечения информации по запросам, стандарт устоялся и щироко используется в корпоративном софтостроении.
Сходство в том, что обе модели основаны на теоретико-графовой иеррхической модели. Но ограничения иерархий тоже известны с 1960-х годов, когда переходили к сетевым и множественным моделям данных.
Более подробно есть в статье "Classification of data models in DBMS" на researchgate и в книжке "СУБД для программиста" (пардон за продакт-плейсмент)
— основная реализация документ-ориентированной модели не JSON, а XML (с версии 2005): нативное хранение, индексация, язык запросов XQuery, поддержка XSD-схем документов. JSON действительно введен в версии 2016 скорее для промежуточного хранения и удобства;
— поддерживается не указанная в сравнительном списке модель «ключ-значение» на основе механизма хеш-таблиц в памяти;
— поддерживается (тoже не указана) многомерная модель — гиперкубы (SQL Server Analysis Services), была еще до версии 2005 под названием MS OLAP.
Тестирование компонента с mock-ами — это типовой модульный тест.
Итеграционный тест «черного яшика» — это что-то из области «сварю суп, бросив в кастрюлю не глядя все с верхней полки холодильника».
Спасибо еще раз, но давайте все же завершим беседу :)
Буду иметь в виду, спасибо :)
Далее переходим к SWEBOK (SoftWare Engineering Base Of Knowlege), где уровни тестирования и примерное число требований/тестов приводятся в виде матрицы. Для модульных речь идет о тысячах, вышестоящие уровни — сотни.
Основное отличие интеграционных тестов от функциональных — whitebox vs blackbox.
Соотношение кода тестов к тестируемому также максимально для модульных, минимум где-то 2:1. Для API уровня 1:10.
Не лучше ли требовать со студентов решение с JOIN-ами вместо подзапросов, приучать к хорошему стилю?
— система зажигания
— система торможения
— распределение и КП
1 и 3 отпадают, 2 более долговечно в электрокаре.
Данные исследования Национального Института Потрбления