none
использовать bcs или поступить как нибудь по другому.... RRS feed

 > 

  • Вопрос

  • Question
    Нужно войти
    1
    Нужно войти

    Доброго дня! у меня возник вопрос а как лучше сделать и что будет потом. Вопрос состоит в следующем...у меня должен быть справочник контрагентов где-то в 150 тысяч  элементов, может и больше. Данный справочник будет использоваться на многих коллекциях сайтов. Тобишь размещаться он будет на корне., так же в других списках будут создаваться lookup поля на справочник контрагентов.

    Как правильно организовать структуру?...я полагаю что нужно создать sql таблицу(контрагент) и использовать технологию bcs( не сталкивался с этой технологией, но немного читал),но я точно не уверен стоит ли так делать и будет ли внешний список обладать всеми функциями что и обычный список... как лучше всего поступить?

    Так же хотел бы узнать...у меня будет много сущнестей с очень большим кол-вом данных от 500к и больше...и как я понимаю использование списков здесь не вариант.

    Но в некоторых случаях когда данных не так много использование списков это хорошая идея, НО списки и sql таблицы нужно как то между собой связывать с помощью lookup подстановок...получается нужно будет писать свои столбцы, которые будут получать данные из sql таблиц? или как то можно еще решить данные проблему используя какие нибудь технологии

    16 июня 2015 г. 11:21
    |

Ответы

  • Question
    Нужно войти
    6
    Нужно войти

    Добрый день,

    я бы на вашем месте использовал SQL только в том случае, если необходимо передавать данные в другие системы для синхронизации. Справочник контрагентов - это очень большая проблема в принципе, которую обычно решают заведением контрагентов в 1С и синхронизацией с другими системами.

    Если для вас предпочтительнее вариант хранения или заведения контрагентов в SharePoint, то при необходимости выгрузки в другие системы можно использовать SQL как промежуточную платформу и использовать Службы SQL Server Integration Services или Master Data Services

     Основная проблема такого справочника - обеспечение уникальности данных и актуальности. 150к элементов - не так и много, однако один и тот же контрагент может менять реквизиты, адреса, да и наименование... Вот там и начинаются проблемы...

    • Помечено в качестве ответа Kadackiy Dmitriy 19 июня 2015 г. 14:08
    16 июня 2015 г. 13:16
    |

Все ответы

  • Question
    Нужно войти
    6
    Нужно войти

    Добрый день,

    я бы на вашем месте использовал SQL только в том случае, если необходимо передавать данные в другие системы для синхронизации. Справочник контрагентов - это очень большая проблема в принципе, которую обычно решают заведением контрагентов в 1С и синхронизацией с другими системами.

    Если для вас предпочтительнее вариант хранения или заведения контрагентов в SharePoint, то при необходимости выгрузки в другие системы можно использовать SQL как промежуточную платформу и использовать Службы SQL Server Integration Services или Master Data Services

     Основная проблема такого справочника - обеспечение уникальности данных и актуальности. 150к элементов - не так и много, однако один и тот же контрагент может менять реквизиты, адреса, да и наименование... Вот там и начинаются проблемы...

    • Помечено в качестве ответа Kadackiy Dmitriy 19 июня 2015 г. 14:08
    16 июня 2015 г. 13:16
    |
  • Question
    Нужно войти
    1
    Нужно войти

    справочник контрагентов будет использоваться только на портале sharepoint и не будет интегрироваться с другими системами...меня просто пугает объем данных для списка....я просто думаю, что такое кол-во хранить в списке не очень хорошая идея(возникнут проблемы с производительностью). и потом данный справочник будет увеличиваться и возможно дойдет до 250к.

    Я общался с некоторыми людьми, которые занимаются шариком и они говорили, что большие объемы лучше хранить в sql... это ведь так?

    17 июня 2015 г. 12:24
    |
  • Question
    Нужно войти
    0
    Нужно войти
    судя по этому видеоуроку список шарика может поддерживать до 50млн элементов...но есть свои пороговые ограничения. Какого ваше мнение ? что лучше использовать для большого объема данных списки или sql таблицы?
    17 июня 2015 г. 16:57
    |