Если производитель указывает технические характеристики каждого канала усиления, а не усилителя в целом, то 90 Вт потребляемой мощности вполне хватит, чтобы получить 60 Вт с канала выходной. Лжи нет. Есть маркетинговая уловка.
Зачем рассматривать искажения _формы сигнала_? Человеческое ухо не может услышать чистый меандр/пилу.
В случае с OLAP кубами агрегировать на уровне ETL, как правило, не надо. Достаточно определить агрегаты на уровне куба (это делается с помощью простого визарда). Сервер рассчитает агрегаты в момент процессинга куба, а при выполнении запроса сам определит, какой из агрегатов использовать наиболее выгодно. В этом и есть фишка ОЛАП.
Да, вы поступили совершенно правильно (исходя из ваших вводных). Просто в моем случае самый большой известный мне куб (мы делаем серийное решение и данные не обо всех инсталляциях мне известны) процессится порядка 200 минут. Не могу не обращать на это внимание.
Свой первый куб я делал вообще без хранилища. Прямо на представлениях поверх 1Совских таблиц. И знаю, что многие и сейчас так делают. Создавать хранилище действительно дорого.
SSRS хорошо подходит для создания регламентированной отчетности. Но совершенно не подходит для аналитической (ad-hoc). Просмотр информации по стране в целом (как в случае у автора поста) — это скорее аналитическая отчетность. Тут OLAP-у не будет равных.
Более того, SSRS — это средство доступа к данным (front-end) и в этом смысле его корректнее сравнивать с Excel-ем, а не с SSAS.
У вас не так много деталей реализации описано, чтобы обратить на что-то внимание. Вот за NULL-ы зацепился. Вы, в общем, правильно сделали, что не стали пропускать NULL-ы в хранилище по умолчанию. Возможно, вам когда-нибудь пригодится отразить в хранилище именно _отсутствие связи_, а не просто неизвестную ссылку. Вот тогда ими и воспользуетесь.
Не понравилась снежинка. С ней все хорошо до тех пор, когда данных не очень много. Когда счет пойдет на сотни гигабайт, то время процессинга на снежинке будет сильно хуже, чем на звезде (из-за более сложных запросов). Хотя, конечно же это зависит от вашего железа. Ну и объемов.
Еще не видно, используете ли вы суррогатные ключи для измерений или родные 1С-вские. Перейдя с char(9) на int можно здорово уменьшить размер таблиц фактов и, следовательно, увеличить скорость выполнения запросов. Еще бы они вам пригодились для Distinct Count'ов при секционировании, но у вас Standard Edition и секционирования у вас нет.
Очень хотелось бы узнать, как можно извлекать данные из 1С через ее штатные интерфейсы, а не залезая в БД.
Наличие NULL-ов в таблице фактов приводит к ошибкам при процессинге многомерной базы данных
Обработка NULL-ов при процессинге настраивается: Cube — Dimension Usage — Define Relationship — Advanced — Measure Group Bindings — Null Processing. Там есть несколько вариантов.
Как правило, ширина интернет канала на порядки ниже пропускной способности диска, а значит диск не может являться фундаментальным ограничением.
Просто увеличьте размер кэша (и на чтение и на запись) в вашем торрент-клиенте (uTorrent, например, позволяет это сделать)
Сейчас тоже думаю об автоматизации дома (в первую очередь свет, во-вторую отопление). Сначала долго смотрел на DALI. Потом узнал про KNX, но так и не нашел дешевых (читай китайских) компонентов.
Очень интересно будет узнать о вашем опыте (у меня куча вопросов). Жду статью =)
А тестировщики есть. И должны были проверить. Но процесс сбойнул и в итоге не проверил никто. Вообще никто. Т.е. косяк в процессе явно присутствует.
Но разработчик-то не проверил свой код — с этим что делать?
Вероятно, автор имеет в виду ситуацию, когда разработчик даже ни разу не запустил написанный код, и в итоге оказалось, что продукт не проходит даже проверку «на дым» — т.е. критический баг лежит на поверхности. В этом, конечно же, вина разработчика присутствует.
А вот то, что такой продукт попал к клиенту — это конечно же вина менеджера, т.к. явно нарушен процесс.
Простой и ненапряжный? Вот мне так не кажется. Написать хорошую статью (не пересказать новости, а именно написать) на актуальную тему — это очень постараться надо.
Не понимаю, почему студент должен получать только выгоду от вложения в компанию своей идеи, но при этом не нести риски (а если эта идея приведет к снижению рейтинга сайта и, как следствие, краху компании?)
Выдача опциона, имхо — самый разумный вариант за вклад такого рода.
Опционы — довольно распространенный инструмент премирования (когда речь идет о действительно крупных премиях). Правда, применяется он в основном к высшему руководству компаний.
Согласен с автором, реализация поиска от Яндекса — далека от идеала.
Во-первых, это не приложение, а мобильная версия сайта, а значит, надо ждать пока он загрузится, чтобы начать искать (результаты, понятное дело, все равно из интернета).
Во-вторых, дизайн страницы с результатами поиска не соответствуют стилю Metro, и как следствие воспринимается как нечто чужеродное.
Поэтому при покупке самым главным вопросом было — есть ли возможность сменить Яндекс на Bing. Продавцы в салоне утверждали, что нет, майкрософтовцы тоже молчали.
Но решение все же нашлось: достаточно изменить язык браузера и поиска на Английский (Настройки — Регион+Язык — Язык браузера и поиска — Английский).
С трудом могу себе представить оправдание для потери «нескольких транзакций». Разве можно подобным образом проектировать системы для бизнеса (да и вообще)?!
Зачем рассматривать искажения _формы сигнала_? Человеческое ухо не может услышать чистый меандр/пилу.
Свой первый куб я делал вообще без хранилища. Прямо на представлениях поверх 1Совских таблиц. И знаю, что многие и сейчас так делают. Создавать хранилище действительно дорого.
Более того, SSRS — это средство доступа к данным (front-end) и в этом смысле его корректнее сравнивать с Excel-ем, а не с SSAS.
Не понравилась снежинка. С ней все хорошо до тех пор, когда данных не очень много. Когда счет пойдет на сотни гигабайт, то время процессинга на снежинке будет сильно хуже, чем на звезде (из-за более сложных запросов). Хотя, конечно же это зависит от вашего железа. Ну и объемов.
Еще не видно, используете ли вы суррогатные ключи для измерений или родные 1С-вские. Перейдя с char(9) на int можно здорово уменьшить размер таблиц фактов и, следовательно, увеличить скорость выполнения запросов. Еще бы они вам пригодились для Distinct Count'ов при секционировании, но у вас Standard Edition и секционирования у вас нет.
Обработка NULL-ов при процессинге настраивается: Cube — Dimension Usage — Define Relationship — Advanced — Measure Group Bindings — Null Processing. Там есть несколько вариантов.
Просто увеличьте размер кэша (и на чтение и на запись) в вашем торрент-клиенте (uTorrent, например, позволяет это сделать)
Очень интересно будет узнать о вашем опыте (у меня куча вопросов). Жду статью =)
Но разработчик-то не проверил свой код — с этим что делать?
А вот то, что такой продукт попал к клиенту — это конечно же вина менеджера, т.к. явно нарушен процесс.
Выдача опциона, имхо — самый разумный вариант за вклад такого рода.
Во-первых, это не приложение, а мобильная версия сайта, а значит, надо ждать пока он загрузится, чтобы начать искать (результаты, понятное дело, все равно из интернета).
Во-вторых, дизайн страницы с результатами поиска не соответствуют стилю Metro, и как следствие воспринимается как нечто чужеродное.
Поэтому при покупке самым главным вопросом было — есть ли возможность сменить Яндекс на Bing. Продавцы в салоне утверждали, что нет, майкрософтовцы тоже молчали.
Но решение все же нашлось: достаточно изменить язык браузера и поиска на Английский (Настройки — Регион+Язык — Язык браузера и поиска — Английский).