Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Mandarin
Member

Откуда: Саратов
Сообщений: 1194
Всем привет! Хочу поделиться мыслями и услышать ваши комментарии на тему "Горизонтальное масштабирование".
Опишу кратко систему которую нужно масштабировать.
1. Классическая трехзвенка. Клиент -> Сервер приложений -> БД
2. Клиент - Delphi десктоп, Сервер приложений - Tomcat (знаю что не сервер приложений, а контейнер сервлетов, не суть), БД - MS SQL Server две машины AlwaysOn
3. В БД примерно 1000 таблиц и 6500+ харнимых процедур.
4. Задача системы OLTP + OLAP
6. Размер БД примерно 1 ТБ.
7. Нагрузка на кластер БД, не очень большая, НО с учётом прироста клиентов, сложности запросов в БД, и низкого качества написания хранимых процедур, читающая реплика периодически встаёт в раскоряку и перестаёт обрабатывать запросы.
8. Размер БД постоянно растёт.
Это очень кратко о том что есть сейчас.
Теперь о том как бы я хотел сделать.
При увеличении количества клиентов, я бы хотел добавить ещё один кластер БД и часть клиентов перевести на новый кластер, маршрутизацию между кластерами обеспечивали бы серверные приложения в Tomcat. Например приходит ко мне коммерческий отдел и говорит "Завтра нагрузка вырастет вдвое" я говорю "Не вопрос подключаю новый кластер, новые клиенты будут работать на нём". Это идеальная ситуация :)
Какие плюсы я вижу в таком подходе
1. Возможность обработать любое количество данных
2. Возможность снизить уровень квалификации разработчиков, которые пишут SQL код,
"Другого народа у нас нет, будет работать с тем что есть" - И.В. Сталин :)
3. Минимизировать проблемы связанные с всплеском нагрузки из-за кривого SQL
4. Сократить объёмы БД в кластере, чтобы ускорить обслуживание БД.
5. Минимизировать ущерб при сбоях БД, сломался один кластер - живет второй.
Если реализовать, то что я хочу на продуктах Microsoft то придется продать здоровую почку чтобы купить лицензии, кстати может ещё и не хватить :) Денег всё это удовольствие стоит космических. Я было подумал, может расширять инфраструктуру на open spurce решениях, например linux + postgresql, но если учесть сложность инфраструктуры, то на создание похожей БД уйдёт очень много времени а это как минимум ЗП разработчикам + баги которые будут в процессе разработки. Вот никак не определюсь с решением что выбрать. Отдать деньги нашим "Пппартнёрам" как скажет В.В., и в кратчайшие сроки получить горизонтальное масштабирование или заморочиться и потратить время и нервы на то чтобы уйти на open source.
Как бы поступили вы?
16 сен 18, 10:05    [21675836]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1723
Возможно, я очень наивный человек, но почему бы сначала не переписать те K или N процедур, которые создают максимум проблем?
Ну и/или оперативки добавить и/или HDD на SSD заменить?
16 сен 18, 11:00    [21675856]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
nvv
Member

Откуда:
Сообщений: 54
Mandarin,
Что-то у вас с терминологией не так... Что вы называете кластером? Зачем вам два кластера?
Почему вы называете sql (mssql ???) кривым? Или речь о коде, о t-sql?
Я скорее интересующийся, чем знающий. Но как вы собрались переезжать, портировать хранилки на pg? Или это все на уровне сервера приложений, и он уже умеет работать с разными СУБД?
16 сен 18, 11:44    [21675872]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
Mandarin
При увеличении количества клиентов, я бы хотел добавить ещё один кластер БД и часть клиентов перевести на новый кластер, маршрутизацию между кластерами обеспечивали бы серверные приложения в Tomcat. Например приходит ко мне коммерческий отдел и говорит "Завтра нагрузка вырастет вдвое" я говорю "Не вопрос подключаю новый кластер, новые клиенты будут работать на нём". Это идеальная ситуация :)
Какие плюсы я вижу в таком подходе
1. Возможность обработать любое количество данных
2. Возможность снизить уровень квалификации разработчиков, которые пишут SQL код,
"Другого народа у нас нет, будет работать с тем что есть" - И.В. Сталин :)
3. Минимизировать проблемы связанные с всплеском нагрузки из-за кривого SQL
4. Сократить объёмы БД в кластере, чтобы ускорить обслуживание БД.
5. Минимизировать ущерб при сбоях БД, сломался один кластер - живет второй.
...
Как бы поступили вы?
1. Да, горизонтальное масштабирование позволяет снять ограничения на масштаб. Хотя пока непонятно, не решаются ли ваши проблемы значительно более дешёвыми способами. База у вас по размеру мизерная, но какая нагрузка - не знаю. Думаю, что размеры и нагрузка так и останутся мизерными, судя по предполагаемой области применения.
2. Специалисты для разработки распределённой системы нужны более квалифицированные, и соответственно, дорогие.
3. Ну конечно, наращивать железо будет проще, чем для нераспределённой системы.
4. Тоже да, хотя непонятно, что даст вам сокращение, объёмы же и так небольшие.
5. Да, в распределённой системе больше резервных узлов. хотя нераспределённые системы тоже обеспечивают достаточное резервирование, до 4х узлов, насколько я помню, неужели этого не хватит?

Повторю, в принципе плюсы верные, но сложность и стоимость распределённого решения будет намного выше, а нужно ли это для повышения нагрузочной способности - из вашего рассказа непонятно. Притом, что вы даже не можете себе позволить вменяемого БД-программиста, что уж говорить о расходах на Такое.
16 сен 18, 13:09    [21675910]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Mandarin
Member

Откуда: Саратов
Сообщений: 1194
DaniilSeryi
Возможно, я очень наивный человек, но почему бы сначала не переписать те K или N процедур, которые создают максимум проблем?
Ну и/или оперативки добавить и/или HDD на SSD заменить?

Переписать хранимки конечно можно, оптимизация хранимок это ежедневный труд программистов, но дело не только в хранимках, дело еще в самих данных, даже наверное не в данных, а в наших персоналиях, в том числе и во мне, мы не умеем работать с такими данными, нам проще когда есть много маленьких БД. Вот например, ночью у нас выполняются всякие оптимизации БД пересчёты витрин, билинг, усушка утруска бд и т.п. и т.д. заканчивается всё это резервным копированием. Иногда эти процессы могут занимать 6-7 часов, иногда быстрее.
Это при том что БД пример 1 ТБ, а если она будет 10 ТБ... в общем работать то будет но не так как мне хотелось бы :)
Вы говорите про замену СХД, мы пользуемся арендованными серверам, там по дискам особо не разгуляешься, 8 дисков на сервер, там конечно стоит уже ssd правда БД крутится в виртуалке, возможно при переносе на железо будет работать быстрее, надо будет попробовать, но так или иначе это называется вертикальное масштабирование, а оно имеет придел, а имперские амбиции не любят когда есть придел :))
16 сен 18, 16:52    [21676021]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Mandarin
Member

Откуда: Саратов
Сообщений: 1194
nvv
Mandarin,
Что-то у вас с терминологией не так... Что вы называете кластером? Зачем вам два кластера?
Почему вы называете sql (mssql ???) кривым? Или речь о коде, о t-sql?
Я скорее интересующийся, чем знающий. Но как вы собрались переезжать, портировать хранилки на pg? Или это все на уровне сервера приложений, и он уже умеет работать с разными СУБД?

Кластером я называю набор машин выполняющих единую задачу. В моём случае это три сервера БД.
1. Пишушая реплика.
2. Читающа реплика.
3. Читающая реплика с отставанием в 15 минут (защита от дурака).
Два кластера мне нужно для того чтобы "крутить" в два раза больше данных. Нагрузка растёт, её надо как то обрабатывать. MS SQL я не называю кривым (специальна написал большими буквами :) ) это крутая СУБД тут даже спорить не стоит. Кривим я называю наш t-sql который работал нормально при малых нагрузках, а сейчас стал "хандрить".
Портировать хранимки я планировал рукам. Плана переезда есть пока два
1. Поэтапный - плюс в том, что модно переводить по 1 таблице, минус в том что придётся делать обратную репликацию для того чтобы старые хранимки, которые ещё не перенесены на новый кластер могли работать с данными
2. Полный -плюс в том что не надо делать обратную репликацию, минус в том что переносить пипец как долго, и можно не успеть за текущими изменениями.
Сервер приложений уже умеет работать с разными БД, как раз там нет проблемы собрать данные с разных машим. Проблема в том, что как только я часть пользователей перевожу на новый кластер, в котором пока 1 таблица (условно), то остальной функционал который я не успел перенести на новый кластер не увидит те данные которые я уже перенёс. Когда я говорю "увидит" я имею в виду селекты с джоинами.
16 сен 18, 17:04    [21676028]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Mandarin
Member

Откуда: Саратов
Сообщений: 1194
alexeyvg
Mandarin
При увеличении количества клиентов, я бы хотел добавить ещё один кластер БД и часть клиентов перевести на новый кластер, маршрутизацию между кластерами обеспечивали бы серверные приложения в Tomcat. Например приходит ко мне коммерческий отдел и говорит "Завтра нагрузка вырастет вдвое" я говорю "Не вопрос подключаю новый кластер, новые клиенты будут работать на нём". Это идеальная ситуация :)
Какие плюсы я вижу в таком подходе
1. Возможность обработать любое количество данных
2. Возможность снизить уровень квалификации разработчиков, которые пишут SQL код,
"Другого народа у нас нет, будет работать с тем что есть" - И.В. Сталин :)
3. Минимизировать проблемы связанные с всплеском нагрузки из-за кривого SQL
4. Сократить объёмы БД в кластере, чтобы ускорить обслуживание БД.
5. Минимизировать ущерб при сбоях БД, сломался один кластер - живет второй.
...
Как бы поступили вы?
1. Да, горизонтальное масштабирование позволяет снять ограничения на масштаб. Хотя пока непонятно, не решаются ли ваши проблемы значительно более дешёвыми способами. База у вас по размеру мизерная, но какая нагрузка - не знаю. Думаю, что размеры и нагрузка так и останутся мизерными, судя по предполагаемой области применения.
2. Специалисты для разработки распределённой системы нужны более квалифицированные, и соответственно, дорогие.
3. Ну конечно, наращивать железо будет проще, чем для нераспределённой системы.
4. Тоже да, хотя непонятно, что даст вам сокращение, объёмы же и так небольшие.
5. Да, в распределённой системе больше резервных узлов. хотя нераспределённые системы тоже обеспечивают достаточное резервирование, до 4х узлов, насколько я помню, неужели этого не хватит?

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


Сейчас мы обслуживаем примерно 1 сотую часть клиентов от того количества, которое планируем обслуживать. В ближайший год, по нашим планам, нагрузка вырастет в 2,5 раза. Через три года уже в 4 раза. Мне уже сегодня нужно знать как я справлюсь с этой нагрузкой. Конечно всегда есть железобетонный вариант - отдал деньги майкрософту, скопировал все под копирку и спи спокойно, но деньги придется из своего кармана доставать, а этого очень не хочется делать :)
16 сен 18, 17:08    [21676029]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33644
Блог
Mandarin,

Вынести отчетную нагрузку на отдельный сервер в виде dwh и кубов.
16 сен 18, 17:55    [21676045]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
L_argo
Member

Откуда:
Сообщений: 1209
автор
2. Возможность снизить уровень квалификации разработчиков, которые пишут SQL код,
3. Минимизировать проблемы связанные с всплеском нагрузки из-за кривого SQL
4. Сократить объёмы БД в кластере, чтобы ускорить обслуживание БД.
2. Очень стрёмное желание. Не хватит никаких серверов, чтобы разрулить проблемы.
3. Не получится. Чудес не бывает.
4. Это чисто вопрос проектирования структуры. Хорошая структура изначально рассчитана на "бесконечную" работу с постоянными урезками данных без потери функциональности и производительности.

Проблема сабжа почти наверняка в п.4 : Хаотичный, недокументированный, накостылированный код, который уже поздно/бессмысленно исправлять.
16 сен 18, 20:40    [21676127]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
Mandarin
в наших персоналиях, в том числе и во мне, мы не умеем работать с такими данными, нам проще когда есть много маленьких БД.
Непонятно, почему вы считаете, что так будет дешевле.
Вы идёте по экстенсивному пути, то есть при медленной работе вы просто хотите купить больше серверов.
Это отличный недорогой способ масштабирования, когда речь идёт о небольших нагрузках, потому что программисты стоят дороже железа.
Но когда масштаб увеличивается, становится выгоднее не увеличивать число серверов до 10000, а увеличить качество программистов.
Тем более, что, как я уже писал, создание распределённой системы тоже обойдётся недёшево, в смысле затрат на программистов.

А далее, если масштаб действительно большой, можно подумать и о распределённой системе, но там затраты будут больше. И важно понимание, какая нагрузка будет при масштабировании, действительно нельзя её обслужить одним небольшим сервером, при грамотно написанной системе?
Mandarin
Сейчас мы обслуживаем примерно 1 сотую часть клиентов от того количества, которое планируем обслуживать. В ближайший год, по нашим планам, нагрузка вырастет в 2,5 раза. Через три года уже в 4 раза. Мне уже сегодня нужно знать как я справлюсь с этой нагрузкой.
То есть выгоднее затратить деньги на создание распределённой системы, на покупку 4х серверов вместо одного, только что бы не нанимать
специалиста по БД?
Мне кажется, это не экономия.

Думаю, это, с одной стороны, непонимание, за что платят этим зажравшимся сиквелистам, а с другой, вы, как любой не-сиквелист, хотите сделать что то крутое, многоуровнево-распределённое, с шинами и фабриками
16 сен 18, 22:15    [21676186]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Mandarin
Member

Откуда: Саратов
Сообщений: 1194
Спасибо за ваши ответы.
17 сен 18, 07:17    [21676300]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2394
Критик
Mandarin,

Вынести отчетную нагрузку на отдельный сервер в виде dwh и кубов.

+1
17 сен 18, 10:15    [21676414]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50774
Mandarin
Кластером я называю набор машин выполняющих единую задачу. В моём случае это три сервера БД.
1. Пишушая реплика.
2. Читающа реплика.
3. Читающая реплика с отставанием в 15 минут (защита от дурака).
Два кластера мне нужно для того чтобы "крутить" в два раза больше данных.

Для этого не надо добавлять новый кластер, достаточно добавлять новые ноды в уже существующий кластер. Две читающие реплики, три читающие реплики... Лучше всего, конечно, пять читающих реплик.

Сразу предупреждаю: пишущая нагрузка так просто не масштабируется, для неё придётся делать шардинг.
17 сен 18, 13:42    [21676843]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
msLex
Member

Откуда:
Сообщений: 8072
Dimitry Sibiryakov
Сразу предупреждаю: пишущая нагрузка так просто не масштабируется, для неё придётся делать шардинг.


К сожалению, в SQL Server шардинг доступен только в Azure.

Может в в следующей on-premis версии будут подвижки в эту сторону.
17 сен 18, 15:45    [21677076]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
msLex
К сожалению, в SQL Server шардинг доступен только в Azure.
Вы имеете в виду федеративные базы данных? Или хранилища?
И то, и другое давно доступно на on-premise
Странно было бы, если бы в Azure откуда то взялись фичи, отсутствующие в on-premise.
17 сен 18, 18:05    [21677248]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
msLex
Member

Откуда:
Сообщений: 8072
alexeyvg
msLex
К сожалению, в SQL Server шардинг доступен только в Azure.
Вы имеете в виду федеративные базы данных? Или хранилища?
И то, и другое давно доступно на on-premise


Нет, я вот про это https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-introduction
17 сен 18, 19:10    [21677303]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
msLex
alexeyvg
пропущено...
Вы имеете в виду федеративные базы данных? Или хранилища?
И то, и другое давно доступно на on-premise


Нет, я вот про это https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-introduction
ИМХО это не совсем то.
Или, лучше сказать, это не та технология, что можно сказать "в SQL Server шардинг доступен только в Azure"
Про Эластик-сегментирование можно сказать "а ещё при работе с Azure доступны новые средства шардинга на уровне приложения"
17 сен 18, 21:24    [21677409]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
msLex
Member

Откуда:
Сообщений: 8072
alexeyvg
msLex
пропущено...


Нет, я вот про это https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-scale-introduction
ИМХО это не совсем то.
Или, лучше сказать, это не та технология, что можно сказать "в SQL Server шардинг доступен только в Azure"
Про Эластик-сегментирование можно сказать "а ещё при работе с Azure доступны новые средства шардинга на уровне приложения"

Я надеюсь, что это первый шаг к нормальному шардингу. Примерно так было с хранением файлов в SQL, сначала добавили API, через которое можно было синхронизировать каталог и таблицу, а потом реализовали полноценный механизм.
17 сен 18, 21:32    [21677414]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
PizzaPizza
Member

Откуда:
Сообщений: 367
автор
Например приходит ко мне коммерческий отдел и говорит "Завтра нагрузка вырастет вдвое" я говорю "Не вопрос подключаю новый кластер, новые клиенты будут работать на нём". Это идеальная ситуация :)

Первое, что пришло в голову в данном случае - попробовать облако. Там можно ресурсы выделять динамически типа "Не вопрос, завтра добавлю еще пару процессоров и памяти".

Хотя конечно же вопрос остается
alexeyvg
Вы идёте по экстенсивному пути

автор
8. Размер БД постоянно растёт.

У вас видимо довольно специфический проект, в котором постоянно требуется такой объем данных и он еще и растет.
Обычно в оперативном доступе только некоторая часть данных, остальное сжимается/архивируется.
С учетом
автор
Сейчас мы обслуживаем примерно 1 сотую часть клиентов от того количества, которое планируем обслуживать. В ближайший год, по нашим планам, нагрузка вырастет в 2,5 раза.

автор
6. Размер БД примерно 1 ТБ.

Вы не Фейсбук разрабатываете? У Reddit база несжатая до 5 ГБ правда это текст голый. У вас, я так понимаю, бинарные данные в основном?
17 сен 18, 21:53    [21677422]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
PizzaPizza
Member

Откуда:
Сообщений: 367
PizzaPizza
У Reddit база несжатая до 5 ГБ правда это текст голый.

5 TБ конечно же
сорри
17 сен 18, 21:55    [21677424]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
boltnik
Member

Откуда: Калуга/Москва
Сообщений: 144
Некое подобие шардигна делали с помощью peer-to-peer репликации.
18 сен 18, 10:34    [21677729]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
boltnik
Некое подобие шардигна делали с помощью peer-to-peer репликации.
Мы (на прошлой работе, лет 10 назад) тоже делали некое подобие шардинга. Но там была большая нагрузка, до 10 тыщ запросов в секунду на каждый сервер, это куже после тщательно вылизанного кэширования и т.д.

Повторю свою главную мысль, совет для автора: начать с адекватных специалистов по БД, начать с понимания нагрузки, и с понимания, какие решения её выдерживают - понимания с помощью этих специалистов. И потом уже искать решения, которые максимально дёшево будут держать такую нагрузку.
Причём, если есть реалистичный прогноз по нагрузке, можно сдвигать дорогие решения на будущее - зачем вкладывать сейчас кучу денег в решение, которое понадобится ещё нескоро? Наберите первый миллион пользователей, потом уже думайте о распределённой системе.
18 сен 18, 11:25    [21677825]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50774
alexeyvg
Наберите первый миллион пользователей, потом уже думайте о распределённой системе.

Когда они начнут думать, скорее всего окажется, что ни БД, ни архитектура приложения на кластер не укладываются и придётся всё переписывать с нуля. Так что думать лучше бы с самого начала если есть чем.
18 сен 18, 14:23    [21678175]     Ответить | Цитировать Сообщить модератору
 Re: Горизонтальное масштабирование. Вопрос со звёздочкой.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31354
Dimitry Sibiryakov
alexeyvg
Наберите первый миллион пользователей, потом уже думайте о распределённой системе.

Когда они начнут думать, скорее всего окажется, что ни БД, ни архитектура приложения на кластер не укладываются и придётся всё переписывать с нуля. Так что думать лучше бы с самого начала если есть чем.
Перепишут.
Всё равно переписывать, если делать правильную архитектуру, но не нанять квалифицированных людей

Это вообще стандартный подход - сначала стартап делает велосипеды с костылями, а потом, тот стартап который выжил, один из тысячи, делает систему получше. Потом ещё получше.
Вряд ли Цукерберг сделал сразу ту архитектуру, которая у ФБ сейчас, для той, самой первой версии, когда потенциальная аудитория пользователей ограничивалась числом студентов одного ВУЗа.

Есть намного более важные вещи, чем правильная архитектура системы, хотя, конечно, нужно её делать правильно, если это вам ничего не стоит (а в данном случае это не так).
18 сен 18, 19:05    [21678617]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить