Хранить XSLT в SQL Server 2005 с типом xml?

Question

В моем веб-приложении ASP.NET много XSL-файлов. Много. Я генерирую кучу ответов AJAX HTML, используя этот тип общего метода преобразования:

public void Transform(XmlDocument xml, string xslPath) 
{
    ...
    XslTransform myXslTrans = new XslTransform();
    myXslTrans.Load(xslPath);
    myXslTrans.Transform(xml,null, HttpContext.Current.Response.Output);        
}

Я бы хотел переместить определения XSL в SQL Server, используя столбец типа xml. Я хотел бы хранить весь файл XSL в одной строке в SQL, и каждый XSL является автономным (без импорта). Я бы зачитал определение XSL из SQL в мой объект XslTransform.

Примерно так:

public void Transform(XmlDocument xml, string xslKey) 
{
    ...

    SqlCommand cmd = new SqlCommand("GetXslDefinition");
    cmd.AddParameter("@xslKey", SqlDbType.VarChar).Value = xslKey;
    // where the result set has a single column of XSL: "<xslt:stylesheet>..." 
    ...

    SqlDataReader dr = cmd.ExecuteReader();
    if(dr.Read()) {
        SqlXml xsl = dr.GetSqlXml(0);
        XslTransform myXslTrans = new XslTransform();
        myXslTrans.Load(xsl.CreateReader());
        myXslTrans.Transform(xml,null, HttpContext.Current.Response.Output);     
    }   
}

Это простой способ:

• добавить метаданные к каждому XSL, например lastUsed, useCount и т. Д.
• Возможность массового обновления / поиска
• предотвратить много доступа к диску
• избегайте ссылок на относительные пути и упорядочивание файлов
• разрешить изменения XSL без повторного развертывания (я мог бы даже написать страницу администратора, которая выбирает / обновляет XSL в базе данных)

Кто-нибудь пробовал это раньше? Есть ли какие-либо предостережения?

EDIT

Предупреждения, перечисленные респондентами:

• доступ к диску не гарантированно уменьшится
• это сломает xsl: включает

Answer 1

Я храню XSLT в базе данных в моем приложении dbscript . (Однако я храню их в столбце NVARCHAR, поскольку он также работает на SQL Server 2000)

Поскольку пользователи могут редактировать свои XSLT, мне нужно было написать собственный валидатор, который загружает текст TextBox в объект .Net XslCompiledTransform, например так:

    args.IsValid = true;

    if (args.Value.Trim() == "")
        return;

    try
    {
        System.IO.TextReader rd = new System.IO.StringReader(args.Value);
        System.Xml.XmlReader xrd = System.Xml.XmlReader.Create(rd);
        System.Xml.Xsl.XslCompiledTransform xslt = new System.Xml.Xsl.XslCompiledTransform();
        System.Xml.Xsl.XsltSettings xslts = new System.Xml.Xsl.XsltSettings(false, false);
        xslt.Load(xrd, xslts, new System.Xml.XmlUrlResolver());
        xrd.Close();
    }
    catch (Exception ex)
    {
        this.ErrorMessage = (string.IsNullOrEmpty(sErrorMessage) ? "" : (sErrorMessage + "<br/>") +
            ex.Message);
        if (ex.InnerException != null)
        {
            ex = ex.InnerException;
            this.ErrorMessage += "<br />" + ex.Message;
        }
        args.IsValid = false;
    }

Что касается ваших очков:

• файловый ввод / вывод будет заменен сгенерированным базой данных дисковым вводом / выводом, поэтому никакой выгоды там нет

• изменения в развертывании для предоставления сценария INSERT / UPDATE, содержащего новые данные

Answer 2

Я вижу две большие проблемы:

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

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

Приходится соглашаться с параметрами обновления / поиска - вы можете делать что-то с Powershell, но это нужно запускать на сервере, и это не всегда хорошая идея.

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