Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Добрый день, уважаемые.
Перед мной стоит следующая задача и сказано - решать ее на MSSQL...

Суть вопроса моего вот в чем:
1. Есть восемь источников информации, которые способны отдавать данные в количестве ~1500 переменных, каждые 50 мс по протоколу ModBus-TCP. Эти данные необходимо регистрировать.
2. Драйвера, принимающие эти данные, работают асинхронно по отношению друг к другу. Из потока данных каждый драйвер должен формировать еще дополнительные события, примерно 250 событий (значительно реже).
3. И принятые и сформированные данные должны быть синхронизированы по единому времени с точностью до 50 мс.
4. Теперь, вся принятая и сформированная информация,
а это примерно 1500*8 + 250*8 = 12000 + 2000 = 14000 переменных, должна быть сохранена.
5. 2000 переменных это своя структура данных, 12000 переменных своя. Т.е. получается необходимо заполнять две таблицы данных.

6. Но вот теперь, собственно, сам вопрос - если это будет одна конструкция INSERT на 12000 полей, то не есть ли это тяжело для движка SQL? В принципе, есть возможность запись 12000 переменных разбить на восемь INSERT-ов, по количеству источников информации, что тоже не есть хорошо. Или все же лучше один INSERT распространять на три поля: ДатаВремя, номер канала, значение? Но тогда количество INSERT-ов в секунду будет 240 000 - не много ли это для MSSQL?

7. Чтения данных будут крайне редки и никаких требований к скорости выборки не предъявляется - хоть пол дня на запрос.
8. Дальше больше, хранимые данные должны размещаться в сегментах (отдельных файлах БД), каждые сутки пишутся в первичный сегмент глубиной примерно на 60 - 180 суток и параллельно во вторичный сегмент глубиной в одни сутки. При наступлении новых суток монтируется новый вторичный сегмент, а предыдущий уходит в хранилище.
10. Если при запросе на чтение необходимы будут данные отсутствующие в первичном сегменте, то автоматически должны быть смонтированы ряд вторичных сегментов, в которых присутствуют запрашиваемые данные, а после чтения размонтированы.

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

Но руководство выдвинуло требование - решать данную задачу средствами MSSQL...


Всем заранее благодарен за советы и мысли по поводу мною написанного.
17 апр 13, 10:45    [14190907]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Паганель
Member

Откуда: Винница
Сообщений: 22550
AlexKB
Но руководство выдвинуло требование - решать данную задачу средствами MSSQL...
выдвигайте встречное требование - HP Proliant BL2x220c G7
17 апр 13, 10:50    [14190934]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Паганель
AlexKB
Но руководство выдвинуло требование - решать данную задачу средствами MSSQL...
выдвигайте встречное требование - HP Proliant BL2x220c G7

Это что, железяка?
Нет, железо уже есть, какой-то восьми ядерный специализированный SIEMENS-сервер.
17 апр 13, 10:59    [14191025]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
попробуйте сделать 2 решения, потом, если sql server решение провалиться, то как-нибудь политично выкатите свое. 12000 столбцов емнип создать нельзя, используйте
автор
Или все же лучше один INSERT распространять на три поля: ДатаВремя, номер канала, значение
. Вставлять можно не по одному значению, а несколько insert into table (date,channel,value) select дата, номер канала, значение union all select дата, номер канала, значение и т.д.
17 апр 13, 11:00    [14191028]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Паганель
Member

Откуда: Винница
Сообщений: 22550
нда, отмазаться не получится
17 апр 13, 11:01    [14191047]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
сиквел - это не СРВ...сливать всё сперва в файлы (например), затем массовая заливка в БД...в принципе решаемо и с помощью скуля
17 апр 13, 11:05    [14191076]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Мистер Хенки
попробуйте сделать 2 решения, потом, если sql server решение провалиться, то как-нибудь политично выкатите свое. 12000 столбцов емнип создать нельзя, используйте
автор
Или все же лучше один INSERT распространять на три поля: ДатаВремя, номер канала, значение
. Вставлять можно не по одному значению, а несколько insert into table (date,channel,value) select дата, номер канала, значение union all select дата, номер канала, значение и т.д.


Отмазаться не получится...
Вот железный довод в пользу MSSQL от руководства - в Тундре о Cache не знают, в Тундре знают только о MSSQL, возможно...
Веселый довод...
Ну ладно, это политика...

Теперь о земном.
Я не совсем понял принципиальный смысл приведенного Вами INSERT - а.

Это получается все-таки единое обращение к SQL-движку, но выполняющее вставку множества отдельных записей?

Ведь вставку данных в MSSQL должны будут выполнять драйвера обмена, которые тоже нельзя особо напрягать, иначе будет потерян темп приема предоставляемых данных.
Потеря данных при регистрации недопустима.
17 апр 13, 11:09    [14191117]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
автор
5. 2000 переменных это своя структура данных, 12000 переменных своя. Т.е. получается необходимо заполнять две таблицы данных.

Странно ,но в общем можно как то выкрутиться, например идентификатор запипи + FILESTREAM (где хранить будуте просто файлы отчетов) ,все равно по идее - инфа будет приходить в виде файла... вряделе ето будет просто поток переменных,етож какойто пакет..иначе как их разливать то ? Да и откровенно структру у вас не понятна пока..но уверен что скорее всего у вас будет файл на входе. Опять же его можно посмотреть и подумать..точно ли ето 1.2 к колонок в таблице :)
автор
7. Чтения данных будут крайне редки и никаких требований к скорости выборки не предъявляется - хоть пол дня на запрос.
8. Дальше больше, хранимые данные должны размещаться в сегментах (отдельных файлах БД), каждые сутки пишутся в первичный сегмент глубиной примерно на 60 - 180 суток и параллельно во вторичный сегмент глубиной в одни сутки. При наступлении новых суток монтируется новый вторичный сегмент, а предыдущий уходит в хранилище.
10. Если при запросе на чтение необходимы будут данные отсутствующие в первичном сегменте, то автоматически должны быть смонтированы ряд вторичных сегментов, в которых присутствуют запрашиваемые данные, а после чтения размонтированы.
Как то ети пункты сами собой протеворечат друг другу. Зачем иметь значения за 1 день отдельно,а остальные на архиве ? Явно сделано исходя из того,чтоб иметь быстрый доступ к оперативным данным.

Вообщем откровенно не хватает информации ,что понять какого таки вида данные будут идти к вам на вход
17 апр 13, 11:10    [14191127]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
AlexKB
Ведь вставку данных в MSSQL должны будут выполнять драйвера обмена, которые тоже нельзя особо напрягать, иначе будет потерян темп приема предоставляемых данных.
Потеря данных при регистрации недопустима.

нет встравку должно делать приложение которое читает с драйвера инфу и патом вставлем в сиквел ,ИМХО
17 апр 13, 11:12    [14191138]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Knyazev Alexey
сиквел - это не СРВ...сливать всё сперва в файлы (например), затем массовая заливка в БД...в принципе решаемо и с помощью скуля

Сливать в файлы, в принципе, возможно.
Будет непрерывный поток файлов.
А когда заливать в SQL?
Все равно данные будут заливаться в том же объеме.
И доступны они должны быть всегда. Запросы будут очень, очень редко, но данные могут понадобиться буквально через несколько секунд, после появления их вот в таком вот регистраторе.
17 апр 13, 11:13    [14191150]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Glory
Member

Откуда:
Сообщений: 104751
AlexKB
6. Но вот теперь, собственно, сам вопрос - если это будет одна конструкция INSERT на 12000 полей, то не есть ли это тяжело для движка SQL? В принципе, есть возможность запись 12000 переменных разбить на восемь INSERT-ов, по количеству источников информации, что тоже не есть хорошо. Или все же лучше один INSERT распространять на три поля: ДатаВремя, номер канала, значение? Но тогда количество INSERT-ов в секунду будет 240 000 - не много ли это для MSSQL?

1. Как поведет себя ваш "источник информации", если добавление текущих данных займет больше 50мс ? Будет ожидать ? Перезапишет текущие данные ? Потеряет их ? Упадет ?

2. Вы сейчас спрашиваете
- какую схему данных вам сделать под эту задачу ?
- какая теоритическая производительность сервера ?
- какая практическая производительность будет у вашего сервера ?
- как лучше написать insert ?

AlexKB
8. Дальше больше, хранимые данные должны размещаться в сегментах (отдельных файлах БД), каждые сутки пишутся в первичный сегмент глубиной примерно на 60 - 180 суток и параллельно во вторичный сегмент глубиной в одни сутки. При наступлении новых суток монтируется новый вторичный сегмент, а предыдущий уходит в хранилище.

Откуда такая постановка про "отдельный файл БД" ? Таблица без секционирования может храниться только в одном файле.
" пишутся в первичный сегмент и параллельно во вторичный сегмент" - означает, что вы хотите дублировать данные в таблице ? или что будет много таблиц ?
17 апр 13, 11:14    [14191158]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
AlexKB
Knyazev Alexey
сиквел - это не СРВ...сливать всё сперва в файлы (например), затем массовая заливка в БД...в принципе решаемо и с помощью скуля

А когда заливать в SQL?
Все равно данные будут заливаться в том же объеме.

задержку по заливки в СУБД нужно утверждать, то, что данные накапливаются - это хорошо для сиквела, он прекрасно умеет обрабатывать большие объёмы в несколько потоков не лоча эти самые потоки...
обычный множественный (или не дай бог одиночный) инсёрт не позволит вам обработать большой объём в несколько потоков...блокировки и всё-такое
17 апр 13, 11:16    [14191179]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
Maxx
AlexKB
Ведь вставку данных в MSSQL должны будут выполнять драйвера обмена, которые тоже нельзя особо напрягать, иначе будет потерян темп приема предоставляемых данных.
Потеря данных при регистрации недопустима.

нет встравку должно делать приложение которое читает с драйвера инфу и патом вставлем в сиквел ,ИМХО

+1
17 апр 13, 11:20    [14191209]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Данные приходят потоком по протоколу ModBus-TCP, один поток - один источник данных.
Если вовремя данные не прочитали - то они утеряны, что недопустимо!
Источнику данных все равно, если данные не прочитаны, на нем это никак не отразится.
Драйвером я называю приложение, которое общается с источником данных по протоколу ModBus-TCP. Это же приложение и должно заливать полученные данные в MSSQL, предварительно формируя еще и события, после вычитки входящего потока данных от источника, но запись событий должно осуществляться в другую таблицу. Тут главный вопрос, чтобы и сформированные события и сами данные в архивах были синхронизированы по времени.

Структуры данных, конечно же нет, потому как непонятно - какие структуры данных способен обслужить MSSQL при вот такой вот задаче. Но похоже, что это должна быть таблица на 3 поля для самих данных, таблица полей на пять для хранения событий и несколько справочных таблиц (наименования событий, наименования каналов, ...).

Вторичные данные, которые располагаются в сегментах по одному дню необходимы для их транспортировки, переноса. Ну вот требование такое.
Раньше такие вопросы решались просто путем регистрации в отдельных файлах, теперь руководство хочет чтобы регистрация выполнялась средствами MSSQL, чтобы потом можно было проводить анализ зарегистрированных данных путем запросов.

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

Извините, не совсем успеваю, за задаваемыми Вами вопросами, может что и упускаю...
Спасибо что отзываетесь.
17 апр 13, 11:47    [14191447]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Glory
Member

Откуда:
Сообщений: 104751
AlexKB
Данные приходят потоком по протоколу ModBus-TCP, один поток - один источник данных.
Если вовремя данные не прочитали - то они утеряны, что недопустимо!

Однозначно писать все в файлы.

AlexKB
Структуры данных, конечно же нет, потому как непонятно - какие структуры данных способен обслужить MSSQL при вот такой вот задаче. Но похоже, что это должна быть таблица на 3 поля для самих данных, таблица полей на пять для хранения событий и несколько справочных таблиц (наименования событий, наименования каналов, ...).

Схема данных вообще то не зависит от сервера.

AlexKB
Вторичные данные, которые располагаются в сегментах по одному дню необходимы для их транспортировки, переноса. Ну вот требование такое.
Раньше такие вопросы решались просто путем регистрации в отдельных файлах, теперь руководство хочет чтобы регистрация выполнялась средствами MSSQL, чтобы потом можно было проводить анализ зарегистрированных данных путем запросов.

А причем тут файлы базы данных ??? Как они влияют на "чтобы потом можно было проводить анализ зарегистрированных данных путем запросов" ?
17 апр 13, 11:58    [14191574]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
AlexKB
Данные приходят потоком по протоколу ModBus-TCP, один поток - один источник данных.
Если вовремя данные не прочитали - то они утеряны, что недопустимо!
Источнику данных все равно, если данные не прочитаны, на нем это никак не отразится.
Драйвером я называю приложение, которое общается с источником данных по протоколу ModBus-TCP. Это же приложение и должно заливать полученные данные в MSSQL, предварительно формируя еще и события, после вычитки входящего потока данных от источника, но запись событий должно осуществляться в другую таблицу. Тут главный вопрос, чтобы и сформированные события и сами данные в архивах были синхронизированы по времени.

Структуры данных, конечно же нет, потому как непонятно - какие структуры данных способен обслужить MSSQL при вот такой вот задаче. Но похоже, что это должна быть таблица на 3 поля для самих данных, таблица полей на пять для хранения событий и несколько справочных таблиц (наименования событий, наименования каналов, ...).

Вторичные данные, которые располагаются в сегментах по одному дню необходимы для их транспортировки, переноса. Ну вот требование такое.
Раньше такие вопросы решались просто путем регистрации в отдельных файлах, теперь руководство хочет чтобы регистрация выполнялась средствами MSSQL, чтобы потом можно было проводить анализ зарегистрированных данных путем запросов.

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

Извините, не совсем успеваю, за задаваемыми Вами вопросами, может что и упускаю...
Спасибо что отзываетесь.

так а может быть раз все работало с файлами, так и продолжать, а уже файлы с менее строгими требованиями к быстроте выполнения транзакции заливать в БД. У вас же еще звучало что запросы могут выполняться хоть пол дня. Так что актуализация данных в базе для аналитических запросов не так горит по времени. Скажем раз в 5 -10 минут данные из файлов закачиваются в базу.
17 апр 13, 11:59    [14191575]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
dalex1973
Member

Откуда: Польша
Сообщений: 287
AlexKB,
AlexKB
никаких требований к скорости выборки не предъявляется - хоть пол дня на запрос

AlexKB
И доступны они должны быть всегда. Запросы будут очень, очень редко, но данные могут понадобиться буквально через несколько секунд, после появления их вот в таком вот регистраторе.


1. Имхо здесь противоречие.
2. Данные будут аггрегироваться.Имхо это DWH-проект. В эту сторону и нужно копать.
17 апр 13, 11:59    [14191581]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
dalex1973
1. Имхо здесь противоречие.
2. Данные будут аггрегироваться.Имхо это DWH-проект. В эту сторону и нужно копать.


На самом деле, тут никакого противоречия нету.
Все зависит от начала и размера окна анализируемых данных.
Если необходимо выполнить анализ от текущего времени и назад от нескольких десятков секунд до несколько часов, то данные для анализа должны быть доступны сразу же, сам такой анализ может занимать время от нескольких секунд до минут.
А если необходимо выполнить анализ данных начиная с 9 месячной давности да еще и на протяжении нескольких месяцев, то такой анализ может продолжаться хоть несколько часов (это со слов руководства).

Да, я еще забыл сказать. В результате анализа должно быть сформировано некое множество временных точек, которые будут указывать на возможные отрезки времени, которые должны быть более тщательно проанализированы. Далее, выбирая любую временную точку нужно будет осуществлять очень быструю выборку данных просто в пределах времени от начала временной точки и до конечной временной точки, отстоящей от начальной на 60 секунд. Вот как раз этот выбор данных должен осуществляться очень быстро.

Т.е. Выборка данных состоит из двух фаз. Первая фаза - это формирование временных отрезков критических ситуаций, она может выполняться по времени, как я уже говорил.
Вторая фаза - это выборка данных, в пределах окна просмотра по критическим ситуациям. Такая выборка должна выполняться очень быстро. Типа, в ЛистБоксе ткнул на строку и появились данные в таблице, на графике. Тут время должно быть не более 3 секунд.
17 апр 13, 12:38    [14191978]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
AlexKB,смотрите в сторону небольшого оперативного хранилища + DWH на который посадите пару кубов ... вообщем я вижу дето так
17 апр 13, 12:41    [14192023]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Мистер Хенки
так а может быть раз все работало с файлами, так и продолжать, а уже файлы с менее строгими требованиями к быстроте выполнения транзакции заливать в БД. У вас же еще звучало что запросы могут выполняться хоть пол дня. Так что актуализация данных в базе для аналитических запросов не так горит по времени. Скажем раз в 5 -10 минут данные из файлов закачиваются в базу.


Продолжать с файлами не могу - есть указание руководства. А я очень исполнительный человек.
По поводу заливки из файла - ну может выполнять заливку каждые 30 секунд, больше не могу. Иначе регистрация будет сильно отставать от реального процесса.

А насколько ускоряет вот такая агрегатная заливка из файла по сравнению со множеством INSERT-ов? Если есть сравнительные оценки, то приведите пожалуйста.
17 апр 13, 12:43    [14192041]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
AlexKB,

если делать BULK INSERT то пара порядков
17 апр 13, 12:45    [14192069]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 856
Maxx
AlexKB,

если делать BULK INSERT то пара порядков


Хорошо, со вставкой вроде разобрались. Можно будет сформулировать задание, чтобы сделали прототип для испытаний.
Получается, что BULK INSERT должен будет грузить каждые 30 с файл в 170 Mb в таблицу с тремя полями. Главное, чтобы файл успевал загрузиться, чтобы такие файлы не накапливались.

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

Тут пока вопрос, реально ли это в принципе?
Также вопрос, возможно ли все это осуществлять на полном автомате (то что я писал ранее по сегментированию)?

Я не могу даже обсуждать, зачем мне это нужно - это указание руководста.

Да, вот еще, все это будет напрягать еще и периодическая очистка устаревших данных из первичной БД, возможно она будет выполняться один - два раза в сутки.
17 апр 13, 14:47    [14193058]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
AlexKB
Maxx
AlexKB,

если делать BULK INSERT то пара порядков


Хорошо, со вставкой вроде разобрались. Можно будет сформулировать задание, чтобы сделали прототип для испытаний.
Получается, что BULK INSERT должен будет грузить каждые 30 с файл в 170 Mb в таблицу с тремя полями. Главное, чтобы файл успевал загрузиться, чтобы такие файлы не накапливались.

в принципе - мелочь...если всё прально сделать



AlexKB
Maxx
AlexKB,

если делать BULK INSERT то пара порядков

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

секционирование (о котором вам уже несколько раз намекнули) решит вашу задачу...раскладываете по разным ФГ, а затем по отдельности бэкапите/переносите
17 апр 13, 14:53    [14193104]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
AlexKB
Теперь еще очень важный вопрос, тут даже не знаю, куда посмотреть и что почитать - формирование посуточных файлов БД, с возможностью их последующего монтирования.

в ТАКОМ варианте как хотеите именно ВЫ,скорее всего нет
Создайте нужное количество файлов и Файловых груп и играйтесь с секционированием..попробуйте убедить начальство,что так правильно,бо в ихсодном виде задача малехо бредовая,и не должен сервер СУБД каждый день рожать новый файл БД.
17 апр 13, 14:53    [14193105]     Ответить | Цитировать Сообщить модератору
 Re: Перед мной стоит задача, а опыта - ноль...  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
AlexKB

Отмазаться не получится...
Вот железный довод в пользу MSSQL от руководства - в Тундре о Cache не знают, в Тундре знают только о MSSQL, возможно...
Веселый довод...
Ну ладно, это политика...
....


а ведь они правы, большей частью так и есть, имел дело, не с тундрой, но за Уралом и дальше
лучше сразу MSSQL
17 апр 13, 15:05    [14193155]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить