У тебя дети — это без комментариев. Они просто не дадут работать. Проверено на племяннице, с которой пришлось посидеть пару дней. Это была отважная война за ноутбук с 9-леткой. Спас планшет с мультиками и отданный на растерзание айфон. Работа затягивалась на очень длинные интервалы из-за страха за поведение и состояние ребёнка.
4-й год на удалёнке, ребёнку 6 лет и не могу сказать что он мешает, когда дома в рабочее время. Всегда найдёт себе дело чем заняться когда папа по сути недоступен. Тут дело скорее в понимании ребёнком когда и как можно себя вести.
Чего не могу сказать про жену:
— Жена не дома — в её понимании если тебя нет физически на работе то ты как бы не работаешь и у тебя мол куча времени на (уборку, готовку, прогулку до магазина, ...)
— Жена дома — это собственно шум создаваемый деятельностью выше перечисленной
Вернусь ли я в офис? Нет (плюсов и возможностей из дома в разы больше)
--где UserInfo вьюха, которая выдаёт данные о пользователе который запускает запрос
Стандартная функция, для MS SQL это SUSER_NAME(), для IBM DB2 USER()
UserInfo может вернуть, только одну запись, в противном случае, это кривые данные. Не может быть двух пользователей с одним логином.
Нагружать базу групповыми, операциями зло, это затратная задача.
Не могу согласиться. Клиент должен быть максимально прост и работать по схеме взял-отдал, так меньше ошибок и в последствии меньше обновлений.
обрабатывать информацию о пользователе и его действиях в среднем слое
Выносить механизм истории изменений в средний слой (бизнес логики), тоже нехорошо, т.к. он к ней отношения не имеет, а является дополнением к возможностям БД. Да и если найдётся специалист, который имеет доступ править данные непосредственно в базе сведения об этом тоже необходимо фиксировать.
Т.е. есть какая-то особая связь между Change Data Capture и как я понимаю виндовой аутентификацией? или в таблицу всё равно придётся добавить поле с информацией, кто трогал?
Сразу оговорюсь мой вариант напоминает схему Change Data Capture и был разработан для IBM DB2 8.2 задолго до появления MS SQL 2008 и IBM DB2 10(там тоже есть такое).
Пользователь заходит со своим логином, на сервере есть таблица с информацией о пользователе.
Клиент тонкий, его цель в данном случае:
— отдать идентификатор отчёта и какие либо параметры, если требуется
— принять результат запроса и шаблон
— отдать в FastReport
Отчётных форм тысячи, и контролировать их на клиенте проблематично
SELECT
--Шапка отчёта
--где UserInfo вьюха, которая выдаёт данные о пользователе который запускает запрос
(SELECT FIO FROM UserInfo) as FIO,
(SELECT PhoneNumber FROM UserInfo) as PhoneNumber,
(SELECT Address FROM UserInfo) as Address,
--Данные отчёта
T.Column1, T.Column2, T.Column3
FROM Table1 T
преобразуем
SELECT U.FIO, U.PhoneNumber, U.Address, T.Column1, T.Column2, T.Column3
FROM Table1 T
JOIN UserInfo U ON 1 = 1
ON 1 = 1 эквивалентно
SELECT U.FIO, U.PhoneNumber, U.Address, T.Column1, T.Column2, T.Column3
FROM Table1 T, UserInfo U
В данном случае, так даже лучше смотрится, но реально данные приходится брать из нескольких таблиц и тогда, не очень красиво получается, как-бы смешивание разных стандартов.
Теперь понятно к чему вы клоните, но я предпочитаю пользоваться удобными инструментами даже, если приходится их делать самому.
Не понятна цена замусоривания серверов сервисными процедурами, когда их от силы с пол сотни, а процедур отвечающих за бизнес логику порядка полутора тысящ.
Согласен баг UNION, очень хорошее замечание, он даже позволил одной компании сэкономить пол миллиона. А MainTable на самом деле служит ограничивающей выборкой, не всегда нужно брать сумму по всем id, может даже и по одному конкретному оппоненту.
С первой частью поста конечно можно спорить вечно т.к. в каждой СУБД, есть свои нюансы, умные и не очень оптимизаторы. Да и писалась она не как 100% решения, а как возможные альтернативы решения проблем.
Стоимость создания/удаления временной таблицы вы не учитываете?
там было сказано, что
результат тяжелого запроса
при этом стоимость создания временной таблицы несущественна, да и результат может быть незначительным.
А то, что в ней нет индексов?
для временной таблицы всегда можно создать индекс даже в MSSQL.
Вторая часть поста связанная с сопровождением.
Использованием адекватных инструментов
речь о них в посте и не велась, но я таких не встречал, обычно это какие-нибудь неповоротливые комбайны, которые на первый взгляд что-то умеют, а на деле ничего хорошего.
На мой взгляд нет ничего лучше самописного редактора с засветкой таблиц, процедур, функций и с возможностью не закрывать транзакцию.
По поводу сервисных процедур, на мой взгляд запись вида
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'ProcedureName1')
DROP PROCEDURE ProcedureName1;
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'ProcedureName2')
DROP PROCEDURE ProcedureName2;
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'ProcedureName3')
DROP PROCEDURE ProcedureName3;
А по поводу комментирования таблиц и процедур мой вариант очевидно лучше, чем предлагает MSSQL, для сравнения в других СУБД это делается проще
COMMENT ON TABLE Schema.Table IS 'Комментарий таблицы';
COMMENT ON COLUMN Schema.Table.Column IS 'Комментарий колонки';
COMMENT ON PROCEDURE Schema.ProcedureName IS 'Комментарий процедуры';
4-й год на удалёнке, ребёнку 6 лет и не могу сказать что он мешает, когда дома в рабочее время. Всегда найдёт себе дело чем заняться когда папа по сути недоступен. Тут дело скорее в понимании ребёнком когда и как можно себя вести.
Чего не могу сказать про жену:
— Жена не дома — в её понимании если тебя нет физически на работе то ты как бы не работаешь и у тебя мол куча времени на (уборку, готовку, прогулку до магазина, ...)
— Жена дома — это собственно шум создаваемый деятельностью выше перечисленной
Вернусь ли я в офис? Нет (плюсов и возможностей из дома в разы больше)
UserInfo может вернуть, только одну запись, в противном случае, это кривые данные. Не может быть двух пользователей с одним логином.
Нагружать базу групповыми, операциями зло, это затратная задача.
Не могу согласиться. Клиент должен быть максимально прост и работать по схеме взял-отдал, так меньше ошибок и в последствии меньше обновлений.
Выносить механизм истории изменений в средний слой (бизнес логики), тоже нехорошо, т.к. он к ней отношения не имеет, а является дополнением к возможностям БД. Да и если найдётся специалист, который имеет доступ править данные непосредственно в базе сведения об этом тоже необходимо фиксировать.
Сразу оговорюсь мой вариант напоминает схему Change Data Capture и был разработан для IBM DB2 8.2 задолго до появления MS SQL 2008 и IBM DB2 10(там тоже есть такое).
Клиент тонкий, его цель в данном случае:
— отдать идентификатор отчёта и какие либо параметры, если требуется
— принять результат запроса и шаблон
— отдать в FastReport
Отчётных форм тысячи, и контролировать их на клиенте проблематично
преобразуем
ON 1 = 1 эквивалентно
В данном случае, так даже лучше смотрится, но реально данные приходится брать из нескольких таблиц и тогда, не очень красиво получается, как-бы смешивание разных стандартов.
Нет, зачем?
Не понятна цена замусоривания серверов сервисными процедурами, когда их от силы с пол сотни, а процедур отвечающих за бизнес логику порядка полутора тысящ.
там было сказано, что при этом стоимость создания временной таблицы несущественна, да и результат может быть незначительным.
для временной таблицы всегда можно создать индекс даже в MSSQL.
Вторая часть поста связанная с сопровождением.
речь о них в посте и не велась, но я таких не встречал, обычно это какие-нибудь неповоротливые комбайны, которые на первый взгляд что-то умеют, а на деле ничего хорошего.
На мой взгляд нет ничего лучше самописного редактора с засветкой таблиц, процедур, функций и с возможностью не закрывать транзакцию.
По поводу сервисных процедур, на мой взгляд запись вида
смотрится намного информативней и короче, чем
А по поводу комментирования таблиц и процедур мой вариант очевидно лучше, чем предлагает MSSQL, для сравнения в других СУБД это делается проще