Работа со строками SQL-сервера в представлении ... Или в XSLT

Question

Мне передали часть работы, которую я могу выполнить в своем приложении или, возможно, в SQL:

Мне нужно вывести дату из строки, которая может выглядеть следующим образом:

1234567-DSP-01/01-VER-01/01

или как это:

1234567-VER-01/01-DSP-01/01

но может выглядеть так:

00 12345 DISCH 01/01-VER-01/01 XXX X XXXXX

Yay. если это "DSP", тогда я хочу эту дату, если "DISCH", то эту дату.

Я извлекаю данные в представлении SQL Server и был бы рад, чтобы представление преобразовало данные для меня. Мое приложение может сделать это, но добавит время процессора Я мог бы также увидеть, можно ли манипулировать данными до их ввода в БД, я полагаю.

Спасибо за ваше время.

Answer 1

Можно проверить наличие DSP или DISCH, а затем, при необходимости, указать дату.

Например (у меня сегодня нет sqlserver, поэтому я могу проверить синтаксис, извините)

select
  date = case date_attribute
            when charindex('DSP',date_attribute) > 0 then substring(date_attribute,beg,end)
            when charindex('DISCH',date_attribute) > 0 then substring(date_attribute,beg,end)
            else 'unknown'
        end 
 from myTable

Answer 2

не хранить несколько элементов в одном столбце!

сохранить дату в своем собственном столбце при вставке строки!

• добавить новый обнуляемый столбец для даты
• написать обновление, которое извлекает дату и устанавливает новый столбец
• изменить столбец, чтобы он не обнулялся
• исправьте вашу процедуру сохранения, чтобы вытащить дату и вставить ее для вас

Answer 3

Если вы делаете это с учетом времени обработки добавления на SQL, который в целом является более дорогим ресурсом, чем приложение, веб или другой тип клиента.

Я бы порекомендовал вам попытаться отформатировать данные, когда вы вставляете данные или обрабатываете их на уровне приложения. Горизонтальное масштабирование уровня приложения намного проще, чем масштабирование SQL.

Редактировать

Я говорю о том, что физические ресурсы сервера баз данных обычно стоят дороже, чем физически ресурсы правильно спроектированного сервера приложений. Это потому, что очень легко масштабировать приложение по горизонтали, на мой взгляд, на порядок дороже масштабировать сервер БД по горизонтали. Особенно, если вы имеете дело с транзакционной базой данных и нуждаетесь в управлении слиянием

Я не говорю, что это невозможно, просто горизонтальное масштабирование сервера базы данных является гораздо более сложной задачей, а значит, и более дорогостоящим. Единственная причина, по которой я указал на это, заключается в том, что OP выразил обеспокоенность по поводу использования циклов ЦП на сервере приложений и сервера базы данных. Большинство приложений, с которыми я работал, были ориентированными на данные приложениями, которые обрабатывали данные в ГБ, чтобы получить ответ пользователя. Сначала мы поместили все на сервер базы данных, потому что это было проще, чем делать это в классическом asp и vb6 в то время. Со временем сервер БД становился все более и более загруженным, пока масштабирование по вертикали больше не было возможным.

Серверы баз данных также предназначены для извлечения и объединения данных. Вы должны оставить форматирование данных для приложения и бизнес-правил (в общем, конечно)