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

Откуда: урал
Сообщений: 2830
Проектируется система, которая будет содержать платежные транзакции. Транзакций в теории может быть очень много, скажем миллион в час. Каждая запись должна содержать id этой транзакции, id карты с которой пришла, и другие параметры, например дату-время и кучу всего прочего.
Не хочется изобретать велосипед, таких систем наверняка вагоны и маленькая тележка. Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?
24 май 17, 09:16    [20506438]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?
Думаете существует какое-то заклинание по созданию волшебно-быстрой таблицы ? :)

По возможности меньше полей и индексов. Поля желательно минимальной длины.
Некоторые советуют использовать char вместо varchar и краткую дату, если не важны секунды и следующее столетие.
24 май 17, 09:22    [20506457]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
stenford,

вряд ли identity узкое место. Лог, индексы, сама генерация записи, ну и железо...
24 май 17, 09:32    [20506485]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2830
LSV
Думаете существует какое-то заклинание по созданию волшебно-быстрой таблицы ? :)

По возможности меньше полей и индексов. Поля желательно минимальной длины.
Некоторые советуют использовать char вместо varchar и краткую дату, если не важны секунды и следующее столетие.


может и существует, для этого и спрашиваю)
Меньше полей конечно понятно, но их-же не сделаешь меньше чем требуется для работы. Поэтому может например id'шники для строк как-то отдельно генерируются в другой таблице, или вообще разбивается на несколько таблиц или еще что-нибудь в этом роде. Кроме того еще имеет место быть такие вещи как indexed views для хранения остатка по картам что-бы не делать такие запросы на "живой" таблице, все это в результате выполняется внутри транзакции и удлиняет ее, тоже непонятно нормальное решение или как-то таские вещи по-другому делаются
24 май 17, 09:37    [20506509]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2830
TaPaK
вряд ли identity узкое место. Лог, индексы, сама генерация записи, ну и железо...

ну вот и интересует кто уже подобные велосипеды делал и проходил этапы определения что и как можно заоптимизировать
24 май 17, 09:39    [20506518]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleksrov
Member

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

А если In memory поробывать? Не идеал конечно, но если нагрузка и впрямь столь серьезная может и подойдет.
Хотя если честно с банками дело не имел и не знаю как должно быть в этой сфере :)
24 май 17, 09:58    [20506610]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleks2
Guest
aleksrov
stenford,

А если In memory поробывать? Не идеал конечно, но если нагрузка и впрямь столь серьезная может и подойдет.
Хотя если честно с банками дело не имел и не знаю как должно быть в этой сфере :)


Казачок то заслатый!

ЗЫ. Тредстартер - чудак.
Не верит, что "простая таблица" будет работать быстро, но верит, что кучка простых таблиц со сложносочинеными связями будет работать "быстро".

Чудесны дела твои, осподи!
24 май 17, 10:14    [20506674]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
aleksrov
Member

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

Ага, пишу прямиком из Редмонда.
Тут уже была тема что таблицы типа 2012, 2013, 2014, 2015 и т.д. самый быстрый способ :)
24 май 17, 10:39    [20506790]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
aleksrov
aleks2,

Ага, пишу прямиком из Редмонда.
Тут уже была тема что таблицы типа 2012, 2013, 2014, 2015 и т.д. самый быстрый способ :)
это быстрый способ управления, а не работы
24 май 17, 10:41    [20506798]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
invm
Member

Откуда: Москва
Сообщений: 9347
stenford
Транзакций в теории может быть очень много, скажем миллион в час
Это не нагрузка даже для простого домашнего компьютера.
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего.
Наймите для проектирования системы специалиста у которого есть знания, а не подозрения. Иначе рискуете очень долго быть объектом граблетерапии.
24 май 17, 11:31    [20507076]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 827
Задача непонятна. Сколько вешать в граммах то?
Сколько записей вы будете писать, каким способом?
По записи? Пакетно? Bulk insert?
Какая нужна производительность записей?
1000 записей в секунду? 10 000? 100 000? 1 000 000?
Если ограничения - порядка 10 - 20 тысяч записей в секунду, пишете по одной записи, короткими транзакциями, в 1 таблицу - никакой дополнительной оптимизации не надо.
Сгодится совершенно ординарный сервер в ценовом диапазоне до 500 тыс. Дисковую подсистему только продумайте, и, возможно, сеть.

Если вам нужно до 100 000 в секунду, то тоже никакой оптимизации особой не надо.
Нужно много памяти, много ядер (но можно - относительно низкой частоты, не 1С чай), SSD диски (причем под логи - обязательно).
Можно таблицу на секции порезать и по разным дискам, висящим на разных каналах контроллера разнести.
И железяка потребуется несколько суровее.

А вот если речь идет примерно о миллионе в секунду и больше - вот тут уже всё сурово.
Тут уже нужно думать о специализированных решениях (например - Parallel Data Warehouse), и биться с разнесением таблицы по разным серверам и т.д.

А из рекомендаций к архитектуре - всё просто и стандартно.
Одна таблица. Можно широкую, но одну. Если для этого потребуется денормализовать схему данных - денормализуйте.
Короткие типы данных. Где можно использовать фиксированные типы - лучше использовать их. Используйте datetime2 вместо datetime. Там где это возможно, избегайте NULLable полей.
В качестве синтетического ключа - identity (но по нему совершенно необязательно строить кластерный индекс).
Никаких триггеров.
Никаких внешних ключей. Точнее - констрейнтов связанных с ними.
Минимум индексов.
Самый минимум индексов.
Никаких индексированных представлений, особенно сложных.

Если нужна аналитика - лучше ее делать в соседней таблице, в соседней базе или на соседнем сервере.
Если она кричи как нужна здесь и сейчас - то копайте в сторону 2016 сервера и колоночных индексов. Их как раз рекламируют как серебряную пулю для таких случаев.

Как то так, ИМХО...
24 май 17, 11:37    [20507113]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
uaggster,

в общем всё так, только column store убьют вставку
24 май 17, 11:40    [20507124]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
it17
Member

Откуда:
Сообщений: 108
stenford
Есть подозрение что сделав обычную таблицу с identity работать нормально не будет из-за всяких race conditions и прочего. Каким образом делаются таблицы где требуется массированная вставка строк?

Вероятно вопрос касается только 1 поля: какого типа должен быть ключ.
Если сделать ключ по guid и генерить его на клиенте, то вставки будут работать быстрее, чем на Identity при условии что данные валятся от разных коннектов (например клиентбанк)
Если данные массово переливать из одной тарелки в другую под одним коннектом, оставить identity
24 май 17, 12:04    [20507230]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 827
TaPaK
uaggster,

в общем всё так, только column store убьют вставку

В 2016SP1 они ж кричат, что всё, наконец, заработало быстро и правильно?
Это ж главная фича 2016!
Может кто пробовал уже?
Действительно плохо?
24 май 17, 12:36    [20507436]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
uaggster
TaPaK
uaggster,

в общем всё так, только column store убьют вставку

В 2016SP1 они ж кричат, что всё, наконец, заработало быстро и правильно?
Это ж главная фича 2016!
Может кто пробовал уже?
Действительно плохо?
Оно же не для OLTP
24 май 17, 13:31    [20507750]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2830
uaggster
Задача непонятна. Сколько вешать в граммах то?
Сколько записей вы будете писать, каким способом?
По записи? Пакетно? Bulk insert?
Какая нужна производительность записей?
1000 записей в секунду? 10 000? 100 000? 1 000 000?
Если ограничения - порядка 10 - 20 тысяч записей в секунду, пишете по одной записи, короткими транзакциями, в 1 таблицу - никакой дополнительной оптимизации не надо.
Сгодится совершенно ординарный сервер в ценовом диапазоне до 500 тыс. Дисковую подсистему только продумайте, и, возможно, сеть.

Если вам нужно до 100 000 в секунду, то тоже никакой оптимизации особой не надо.
Нужно много памяти, много ядер (но можно - относительно низкой частоты, не 1С чай), SSD диски (причем под логи - обязательно).
Можно таблицу на секции порезать и по разным дискам, висящим на разных каналах контроллера разнести.
И железяка потребуется несколько суровее.

А вот если речь идет примерно о миллионе в секунду и больше - вот тут уже всё сурово.
Тут уже нужно думать о специализированных решениях (например - Parallel Data Warehouse), и биться с разнесением таблицы по разным серверам и т.д.

А из рекомендаций к архитектуре - всё просто и стандартно.
Одна таблица. Можно широкую, но одну. Если для этого потребуется денормализовать схему данных - денормализуйте.
Короткие типы данных. Где можно использовать фиксированные типы - лучше использовать их. Используйте datetime2 вместо datetime. Там где это возможно, избегайте NULLable полей.
В качестве синтетического ключа - identity (но по нему совершенно необязательно строить кластерный индекс).
Никаких триггеров.
Никаких внешних ключей. Точнее - констрейнтов связанных с ними.
Минимум индексов.
Самый минимум индексов.
Никаких индексированных представлений, особенно сложных.

Если нужна аналитика - лучше ее делать в соседней таблице, в соседней базе или на соседнем сервере.
Если она кричи как нужна здесь и сейчас - то копайте в сторону 2016 сервера и колоночных индексов. Их как раз рекламируют как серебряную пулю для таких случаев.

Как то так, ИМХО...


спасибо, полезная информация.
Предположим убрали внешние ключи, индексы и таблицу оставили кучей. Однако с информацией в таблице-то все равно надо как-то работать, надо по запросу показать к примеру все транзакции определенной карты, как минимум индекс по id карты получается должен быть, посчитать баланс карты - тут index view'шки нужны, не высчитывать-же его на боевой таблице на каждый чих. Причем не получится его как-то постфактум слить в другую таблицу и посчитать там - баланс должен быть актуален немедленно что-бы карта в минус не ушла пока аналитика где-то там пересчитывается. Как все эти проблемы решаются? Точное число транзакций неизвестно, это зависит от обьема бизнеса, сегодня может быть небольшой, те-же несколько тысяч в секунду, но через пару лет могут до сотен тысяч вырасти - не перекраивать-же систему из-за этого, архитектурно надо сразу правильно сделать с прицелом на большие обьемы
Про колоночные индексы почитаю, но до 2016 как-то эти проблемы-же решались?
24 май 17, 13:31    [20507755]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
stenford
Предположим убрали внешние ключи, индексы и таблицу оставили кучей. Однако с информацией в таблице-то все равно надо как-то работать, надо по запросу показать к примеру все транзакции определенной карты, как минимум индекс по id карты получается должен быть
Не надо без индексов. Просто минимизируйте их количество.
stenford
посчитать баланс карты - тут index view'шки нужны, не высчитывать-же его на боевой таблице на каждый чих
Можно хранить баланс в другой таблице, в картах.
stenford
через пару лет могут до сотен тысяч вырасти - не перекраивать-же систему из-за этого, архитектурно надо сразу правильно сделать с прицелом на большие обьемы
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.
24 май 17, 14:36    [20508085]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
человек_ниоткуда
Guest
alexeyvg
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

дА!

uaggster
Как то так, ИМХО...

Да! Собственно вопрос к топикастеру кто и как туде будет данные всувать? Много клиентов, или один/два сервиса платежей - пачками. Пачками вероятно быстрее.

И Да. Но...
А почему денормализовать? Разьве не лучше что там были только ключи и данне (сумма платежа т.е.). Тогда вставщих сможет себе закешировать наборы ключей классификаторов и формировать готовую запись на своей стороне.

А почему секции? Ну вернее, как вариант для тестирования, я б попробовал сделать "горячую" секцию в виде таблицы без индексов вообще, на отдельной файловой группе; и "рабочую" секцию в виде таблицы с кластерником и минимумом нужных индексов.
Вставка транзакций велась бы в горячую секцию, а в рабочую производился бы периодический перенос данных. Далее горячую секцию на N-файлов раскидать (т.е. файлгруппа из N-файлов), чтоб уменьшить вероятность зависонов из-за LACH блокировок на GAM, SGAM и т.п.
24 май 17, 15:14    [20508251]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 827
человек_ниоткуда
alexeyvg
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

дА!

uaggster
Как то так, ИМХО...

...
А почему денормализовать? Разьве не лучше что там были только ключи и данне (сумма платежа т.е.). Тогда вставщих сможет себе закешировать наборы ключей классификаторов и формировать готовую запись на своей стороне.

Имелось ввиду, чтобы не осуществлялась вставка в структуру Master-Detail (т.е. заголовочные данные - в одной таблице, расшифровка по позициям - во второй и т.д.)
То, что можно использовать коды справочников - это понятно.
Вот только в высоконагруженных системах нежелательно привязывать эти справочники с помощью декларативной ссылочной целостности.
Оно, конечно, потенциальная дыра в консистентности информации, но поддержание этих связей уж очень больно по производительности вставок/удалений/изменений бьёт.

человек_ниоткуда
А почему секции? Ну вернее, как вариант для тестирования, я б попробовал сделать "горячую" секцию в виде таблицы без индексов вообще, на отдельной файловой группе; и "рабочую" секцию в виде таблицы с кластерником и минимумом нужных индексов.
Вставка транзакций велась бы в горячую секцию, а в рабочую производился бы периодический перенос данных. Далее горячую секцию на N-файлов раскидать (т.е. файлгруппа из N-файлов), чтоб уменьшить вероятность зависонов из-за LACH блокировок на GAM, SGAM и т.п.

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

Кстати, по Вашей схеме можно просто 2 таблицы соорудить: горячую (за текущий день, час и т.д.) и холодную неизменяемую, с кучей индексов, колоночных в т.ч.
24 май 17, 15:55    [20508433]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
uaggster
Member

Откуда:
Сообщений: 827
alexeyvg
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.

Вот тут не согласен.
100 тысяч траназкций в секунду может быть 10 минут в сутки :)
24 май 17, 16:03    [20508477]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
uaggster
alexeyvg
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.

Вот тут не согласен.
100 тысяч траназкций в секунду может быть 10 минут в сутки :)
Ну, собственно, это вопрос о функциях самой системы.
Это аналитическая система?
Или ОЛТП - платёжная система?

Если первое, то будут пакетные вставки, и вообще тогда эти объёмы не вызывают каких то вопросов.
А во втором случае таких пиков не будет. Просто нет в мире стольких устройств - источников платежей.

В обоих случаях это будет не просто табличка с огромным потоком вставок; неминуемо будут разнообразнейшие запросы и обработки, справочники, и целостность данных для финансовых инструментов важнее быстродействия. А в случае платёжной системы записей в разные таблицы будет намного больше, чем собственно транзакций.

Во втором случае нужно делать распределённую систему, и для надёжности, и для скорости. Если там действительно большие нагрузки (национальная платёжная система?)
24 май 17, 17:11    [20508804]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
человек_ниоткуда
Guest
uaggster
Имелось ввиду, чтобы не осуществлялась вставка в структуру Master-Detail (т.е. заголовочные данные - в одной таблице, расшифровка по позициям - во второй и т.д.)

Ну если в этом смысле, то вопросов нет.

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

Я имелл ввиду секционирование не декларативными инструментами SQL (partiton scheme и т.д.), а именно две таблицы сделать. Маленькую в которую будет вставка новых данных вестись, и большую в которую будет периодическая выгрузка из маленькой делаться.
Резать на секции я считаю надо уже после того как система будет работать в с продуктивной нагрузкой. Т.к. обычно угадать с этим очень трудно. На моём опыте только не очень удачные попытки, когда получалось что в одну секцию 90% потока идёт.

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

Ну так я и предложил, вы прямо эту цитату вырезали. Просто дополнительно таблицу с "горячей" секцией на многофайловую файлгруппу положить.
Опять же - можно и 2 горячих таблицы сделать, и на два канала SAN (я ведь правильно понял что имеется ввиду контроллер SAN) их повесить.
24 май 17, 19:24    [20509202]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2830
alexeyvg
Можно хранить баланс в другой таблице, в картах.

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

alexeyvg
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

сразу делать к примеру то-же секционирование не стоит, согласен, на секции можно пилить и потом, когда обьемы вырастут. Проектирование-же структур таблиц сразу надо делать оптимальным, какой смысл ее делать неверно а затем переделывать?

alexeyvg
Собственно, 100 тысяч траназкций в секунду - это 3000 миллиардов транзакций в год, мне кажется, столько на нашей планете пока нет.

как тут уже написали, может быть спайк активности в короткий промежуток времени, условно в 12 часов все пошли на обед и платят картами. А шлюзы платежных систем (мастеркард к примеру) отслеживает проседание в отклике и при определенном проценте выхода из требуемого времени отклика на компанию-провайдера накладываются нехилые штрафы (сотни тысяч долларов)
25 май 17, 02:25    [20509819]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
stenford
Member

Откуда: урал
Сообщений: 2830
человек_ниоткуда
Да! Собственно вопрос к топикастеру кто и как туде будет данные всувать? Много клиентов, или один/два сервиса платежей - пачками. Пачками вероятно быстрее.

много мелких коннектов, для каждой транзакции шлюз открывает отдельный tcp-ip коннект
25 май 17, 02:28    [20509820]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для транзакций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
stenford
alexeyvg
Можно делать распределённую систему, однако нужно всё таки точнее прогнозировать потребности.
Может быть, разумнее потом глобально перекроить систему, когда возникнет потребность, чем сразу творить монструозную нетленку?

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

Что бы нагрузка составила 100 тыщ транзакций в секунду, нужно, что бы в обед 10 миллионов человек подошли к миллиону терминалов и совершили операции.

Вы будете бслуживать миллион терминалов на старте? Тогда ок, ваши расчёты правильные.
stenford
alexeyvg
Можно хранить баланс в другой таблице, в картах.

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

Я так сразу не могу сказать, что эффективнее, но на мой взгляд эффективнее хранить баланс, особенно при удлинении истории хранения.

Насчёт баги - ну, писать надо правильно.
Это ведь очень простая логика, её вполне реально надёжно, это ведь один оператор апдэйта в триггере.
25 май 17, 09:00    [20510029]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить