<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" >

  <channel>
    <title><![CDATA[Комментарии / Профиль query]]></title>
    <link>https://habr.com/ru/users/query/comments/</link>
    <description><![CDATA[Хабр: комментарии пользователя query]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Wed, 19 Aug 2026 14:46:56 GMT</pubDate>
    
    
      <image>
        <link>https://habr.com/ru/</link>
        <url>https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png</url>
        <title>Хабр</title>
      </image>
    

    
      

      
        
  
    <item>
      <title>04.04.2015 07:38:22</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/254863/#comment_8360917</guid>
      <link>https://habr.com/ru/articles/254863/#comment_8360917</link>
      <description><![CDATA[1. Выборка делалась за год.<br/>
2. Ассортимент приблизительно 2 тыс. наименований.]]></description>
      <pubDate>Sat, 04 Apr 2015 07:38:22 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>04.04.2015 07:36:36</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/254863/#comment_8360915</guid>
      <link>https://habr.com/ru/articles/254863/#comment_8360915</link>
      <description><![CDATA[Тогда получилась бы статья 18+ :) так как речь идет об алкогольной продукции. Не вдаваясь в подробности можно смело сказать, что красное вино хорошо продается в паре с белым аналогичной марки. Так же вина хорошо продаются в паре с игристыми винами (шампанским). Кстати, в магазине, как правило выкладывают красные и белые вина на разных полках. Получается это не совсем правильно. По крайне мере я бы рассмотрел вариант создания отдельной полки для «неискушенных», где выкладка была бы согласно результатам анализа корзины. Так же вариант — сделать подарочные упаковки с уже приготовленными «джентльменскими» наборами. Здесь пусть профессионалы думают и решают, самое главное, что у них теперь есть инструмент.]]></description>
      <pubDate>Sat, 04 Apr 2015 07:36:36 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>03.04.2015 20:14:06</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/254863/#comment_8360601</guid>
      <link>https://habr.com/ru/articles/254863/#comment_8360601</link>
      <description><![CDATA[Думаю да, если заполучить данные конкурентов, например, и с помощью них обнаружить, что товар А, хорошо продается с товаром Б, а у нас, к примеру, товар Б вообще слабо продается, потому что лежит непонятно где (не рядом товаром А).]]></description>
      <pubDate>Fri, 03 Apr 2015 20:14:06 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>03.04.2015 15:38:36</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/254863/#comment_8360161</guid>
      <link>https://habr.com/ru/articles/254863/#comment_8360161</link>
      <description><![CDATA[Вопрос правильный. Если приоткрыть завесу, то в моем случае за кодами товаров скрываются как раз коды групп аналогов или, пользуясь вашей терминологией, группы товаров заменителей.]]></description>
      <pubDate>Fri, 03 Apr 2015 15:38:36 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 12:08:27</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7307417</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7307417</link>
      <description><![CDATA[Наша OLTP БД в ЦО весит 150 Гб. Плюс 30 филиалов, в каждом БД примерно по 15 Гб. Итого 600 Гб.]]></description>
      <pubDate>Thu, 13 Feb 2014 12:08:27 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 11:57:19</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7307353</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7307353</link>
      <description><![CDATA[Спасибо за такой развернутый ответ.<br/>
<br/>
Некоторый опыт работы с 1С у меня есть, поэтому описанное не вызывает вопросов. Очевидно в будущем мы будем использовать и РИБ и СКД.]]></description>
      <pubDate>Thu, 13 Feb 2014 11:57:19 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 09:21:40</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/211885/#comment_7306535</guid>
      <link>https://habr.com/ru/articles/211885/#comment_7306535</link>
      <description><![CDATA[Я не писал, что поле с хешем не нужно, пусть оно остается. Как раз при вставке новой записи оно и потребуется. Я писал, что соединять две таблицы по хешу менее оптимально, чем по полю с типом int.]]></description>
      <pubDate>Thu, 13 Feb 2014 09:21:40 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 09:01:11</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/211885/#comment_7306455</guid>
      <link>https://habr.com/ru/articles/211885/#comment_7306455</link>
      <description><![CDATA[В случае с таблицами dbo.format_profile и dbo.format_history я бы поступил немного иначе. В таблицу dbo.format_profile добавил бы первичный ключ типа int, а в таблице dbo.format_history сделал бы внешний ключ так же типа int. Это немного увеличило бы размер таблиц, но в случае соединения таблиц при выборке дало бы большую производительность запросов, так как операции по считыванию с диска и размещению данных в buffer cache происходили бы по данным типа int (4 байта), а не BINARY(16) (16 байт).]]></description>
      <pubDate>Thu, 13 Feb 2014 09:01:11 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 07:22:01</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7305977</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7305977</link>
      <description><![CDATA[Да, мне тоже было бы интересно сравнить эти продукты. Одно могу предположить смело, что решение на SQL Server и PivotTable Report в Excel будет работать быстрее. Еще один большой плюс решения на SQL Server — это возможность использования других «плюшек» от Microsoft, таких как интеграция с SharePoint, интерактивные отчеты на Power View, подписки на отчеты и т.д… <br/>
<br/>
Если 1С: Консолидация умеет работать с другими источниками данных кроме баз данных на основе конфигураций 1С 8, то это хорошо, а если нет, то при переводе OLTP на другую платформу придется внедрять другой инструмент BI. Моё же решение будет работать вне зависимости от платформы, на которой работает OLTP.<br/>
<br/>
Предполагаю, что 1С максимально упростила процесс настройки решения BI, и, возможно, внедрение этого продукта будет по трудозатратам выгоднее, однако нужно помнить, что 1С: Консолидация стоит денег, а в моем случае решение было построено без покупки дополнительного ПО.<br/>
<br/>
Один критерий, по которому 1С однозначно выигрывает — это количество специалистов на рынке, которых очевидно больше, чем девелоперов Microsoft BI.]]></description>
      <pubDate>Thu, 13 Feb 2014 07:22:01 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>13.02.2014 07:03:20</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7305917</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7305917</link>
      <description><![CDATA[ETL-процесс собирает данные из источников, экспортирует их в хранилище и процессит куб. В таблице фактов есть поле с датой, это означает, что все продажи одного офиса по одному покупателю и одному товару за один день агрегируются в одну строку. Эта агрегация выполняется на уровне view в источнике. Т.е. view dbo.Sales в базе данных 1С представляет данные в сгруппированном виде по офису, клиенту, товару, дню. Агрегация по дням, месяцам, годам происходит не в хранилище, а в многомерной модели данных, путем создания иерархии в измерении «Календарь». Если вы агрегируете данные прямо в хранилище, то, вероятно, вы не используете SSAS, а строите отчеты непосредственно из хранилища данных. Если я прав, то советую вам использовать колоночные индексы в таблице фактов, при условии, что у вас SQL Server 2012.]]></description>
      <pubDate>Thu, 13 Feb 2014 07:03:20 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>12.02.2014 12:43:26</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7303467</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7303467</link>
      <description><![CDATA[SSRS мы используем. Собственно с него и началось мое знакомство с BI от Microsoft. Подписки действительно очень понравились пользователям, привыкшим работать в 1С. У 1С аналога я не видел. Кроме того, большой плюс SSRS заключается в возможности кеширования отчетов. Это позволяет существенно разгрузить SQL-сервер.]]></description>
      <pubDate>Wed, 12 Feb 2014 12:43:26 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>12.02.2014 12:35:25</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7303437</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7303437</link>
      <description><![CDATA[Спасибо. Деталей действительно не много. Описал, можно сказать, вершину айсберга, иначе бы статья получилась слишком большая.<br/>
<br/>
По поводу снежинки. Я решил проверить, насколько быстро будет происходить обновление данных в хранилище и многомерной БД при снежинке. Получилось 20 минут, вполне приемлемо. Решил оставить как есть, но будущее учту ваше замечание. Microsoft в книжке «Implementing a Data Warehouse with Microsoft SQL Server 2012» пишет: «If you do not use OLAP cubes and your reports query your data warehouse directly, then using a Star instead of a Snowflake schema might speed up the reports, because your reporting queries involve fewer joins». Сейчас мы не используем хранилище непосредственно для отчетов.<br/>
<br/>
Я использую суррогатные ключи типа int, 1С-вские char(9) используются только для сопоставления записей в хранилище и базах данных 1С.]]></description>
      <pubDate>Wed, 12 Feb 2014 12:35:25 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>12.02.2014 11:19:44</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7303171</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7303171</link>
      <description><![CDATA[Для этого существует механизм распределенных информационных баз <a href="http://v8.1c.ru/overview/RaspredBases.htm">http://v8.1c.ru/overview/RaspredBases.htm</a><br/>
<br/>
За подсказку по поводу обработки NULL-ов большое спасибо, буду знать. <br/>
<br/>
Поскольку это мое первое BI решение, очень хотелось бы услышать комментарии знатоков, на что еще обратить внимание. В том же вопросе с NULL-ами, как правильнее поступить? Оставить NULL-ы в хранилище и обрабатывать их в кубе при процессинге? Или сразу в хранилище от них избавляться?]]></description>
      <pubDate>Wed, 12 Feb 2014 11:19:44 GMT</pubDate>
      
    </item>
  

  
    <item>
      <title>12.02.2014 11:08:51</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/212349/#comment_7303149</guid>
      <link>https://habr.com/ru/articles/212349/#comment_7303149</link>
      <description><![CDATA[Дело в том, что для целей упр. учета у нас используется очень доработанная конфигурация «1С: Торговля и склад 7.7». Нужно было конечно раньше переходить на 1С 8, но тогда у бизнеса были другие задачи и требования. Сейчас проект по переходу обсуждается, и будущая архитектура решения очень вероятно будет использовать стандартный механизм РИБ, но сколько будет длиться этот переход пока не понятно, очевидно что долго и мучительно. Кроме того, я не думаю, что стандартные отчеты в 1С могут в полной мере заменить возможности анализа данных с помощью многомерных данных, так что BI решение будет развиваться параллельно, вне зависимости от архитектуры решения 1С.]]></description>
      <pubDate>Wed, 12 Feb 2014 11:08:51 GMT</pubDate>
      
    </item>
  


      

      

    
  </channel>
</rss>
