{"id":11147,"date":"2021-05-27T08:01:06","date_gmt":"2021-05-27T15:01:06","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=11147"},"modified":"2025-06-13T19:40:16","modified_gmt":"2025-06-14T02:40:16","slug":"sql-nosql-comparison-aspnet-application","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/sql-nosql-comparison-aspnet-application\/","title":{"rendered":"Comparaci\u00f3n entre SQL y NoSQL: Aplicaci\u00f3n ASP.NET"},"content":{"rendered":"
\n

Esta comparaci\u00f3n de SQL y NoSQL es el siguiente paso despu\u00e9s de convertir tu base de datos SQL Server a Couchbase. En el puesto anterior<\/a>Copi\u00e9 AdventureWorks de SQL Server a Couchbase.<\/p>\n<\/div>\n

\n

En este post, voy a mostrar una aplicaci\u00f3n ASP.NET Core que usa SQL Server, y c\u00f3mo esa misma aplicaci\u00f3n usar\u00eda Couchbase. Si quieres seguir el tutorial, puedes consultar la secci\u00f3n Proyecto SqlServerToCouchbase<\/a> en GitHub.<\/p>\n<\/div>\n

\n

A diferencia del post anterior, no estoy haciendo ning\u00fan intento de conversi\u00f3n \"autom\u00e1tica\" de una aplicaci\u00f3n. En su lugar, piensa en esto m\u00e1s como una comparaci\u00f3n de SQL y NoSQL a nivel de aplicaci\u00f3n.<\/p>\n<\/div>\n

\n

Aplicaciones ASP.NET SQL Server<\/h2>\n
\n
\n

He creado una aplicaci\u00f3n ASP.NET Core REST API muy simple. He utilizado Entity Framework, pero si est\u00e1s usando Dapper, ADO.NET, NHibernate, etc, todav\u00eda debe ser capaz de seguir a lo largo.<\/p>\n<\/div>\n

\n

Cada punto final devuelve JSON. Tambi\u00e9n he a\u00f1adido Swashbuckle al proyecto, para que puedas realizar peticiones directamente desde tu navegador a trav\u00e9s de OpenAPI.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Aplicaci\u00f3n ASP.NET Couchbase Server<\/h2>\n
\n
\n

La versi\u00f3n Couchbase de la aplicaci\u00f3n devuelve los mismos datos, porque est\u00e1 utilizando los mismos datos SQL Server AdventureWorks.<\/p>\n<\/div>\n

\n

En la aplicaci\u00f3n, estoy utilizando el SDK .NET de Couchbase<\/a> y Transacciones Couchbase<\/a> bibliotecas. (Puede utilizar Linq2Base<\/a> como un tipo de sustituci\u00f3n de Entity Framework).<\/p>\n<\/div>\n

\n

Por lo dem\u00e1s, la aplicaci\u00f3n es la misma, proporcionando una comparaci\u00f3n (y contraste) entre SQL y NoSQL. Los endpoints devuelven JSON, y Swashbuckle est\u00e1 instalado.<\/p>\n<\/div>\n

\n

Hay un controlador en cada muestra. Vamos a pasar por cada punto final en el controlador y realizar una comparaci\u00f3n SQL y NoSQL.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n

Comparaci\u00f3n entre SQL y NoSQL: Obtener por ID<\/h2>\n
\n
\n

Empecemos por el GetPersonByIdAsync<\/code> punto final. Dado un ID de persona, este punto final devuelve los datos de Persona para el ID dado.<\/p>\n<\/div>\n

\n

Servidor SQL<\/h3>\n
\n

Aqu\u00ed est\u00e1 el ejemplo de SQL Server utilizando Entity Framework:<\/p>\n<\/div>\n

\n
\n
[HttpGet(\"\/person\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdAsync(int personId)\r\n{\r\n    var person = await _context.Persons\r\n        .SingleOrDefaultAsync(p => p.BusinessEntityID == personId);\r\n\r\n    return Ok(person);\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Tambi\u00e9n escrib\u00ed otra versi\u00f3n de este m\u00e9todo, llamada GetPersonByIdRawAsync<\/code> que utiliza una consulta SQL \"en bruto\". Esta consulta es muy similar a la que Entity Framework (arriba) genera en \u00faltima instancia, y es similar a un enfoque Dapper.<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/personRaw\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdRawAsync(int personId)\r\n{\r\n    var person = await _context.Persons\r\n        .FromSqlRaw(@\"SELECT * FROM Person.Person WHERE BusinessEntityID = {0}\", personId)\r\n        .SingleOrDefaultAsync();\r\n\r\n    return Ok(person);\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Tenga en cuenta que, de cualquier forma, se est\u00e1 ejecutando una consulta SQL.<\/p>\n<\/div>\n
\n
Con N1QL, podr\u00edamos consultar los datos en Couchbase de una manera muy similar. Aqu\u00ed est\u00e1 el GetPersonByIdRawAsync<\/code> en el proyecto Couchbase:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/personRaw\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdRawAsync(int personId)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var cluster = bucket.Cluster;\r\n    var personResult = await cluster.QueryAsync<Person>(@\"\r\n        SELECT p.* FROM AdventureWorks2016.Person.Person p WHERE p.BusinessEntityID = $personId\",\r\n        new QueryOptions().Parameter(\"personId\", personId));\r\n    return Ok(await personResult.Rows.SingleOrDefaultAsync());\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
(Hay un paso extra al pasar de \"bucket\" a \"cluster\". Esto podr\u00eda ser omitido, pero yo uso cubo en otras partes del controlador, as\u00ed que lo dej\u00e9 en).<\/p>\n<\/div>\n
\n
Sin embargo, el uso de una consulta N1QL implica una sobrecarga adicional (indexaci\u00f3n, an\u00e1lisis de consultas, etc). Con Couchbase, si ya conocemos el ID de Persona, podemos saltarnos una consulta N1QL y hacer una b\u00fasqueda directa clave\/valor (K\/V).<\/p>\n<\/div>\n<\/div>\n
\n
Obtener por ID con K\/V<\/h3>\n
\n
La clave ya se conoce; se da como argumento. En lugar de utilizar SQL, vamos a hacer una b\u00fasqueda clave\/valor. Hice esto en un m\u00e9todo endpoint llamado GetPersonByIdAsync<\/code>:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/person\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdAsync(int personId)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var scope = await bucket.ScopeAsync(\"Person\");\r\n    var coll = await scope.CollectionAsync(\"Person\");\r\n    var personDoc = await coll.GetAsync(personId.ToString());\r\n    return Ok(personDoc.ContentAs<Person>());\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
A diferencia de SQL Server, Couchbase soporta una variedad de APIs para interactuar con los datos. En este caso, la b\u00fasqueda clave\/valor extraer\u00e1 el documento Persona directamente de la memoria. No hay necesidad de parsear una consulta SQL o usar cualquier indexaci\u00f3n. Las b\u00fasquedas de clave\/valor en Couchbase a menudo se miden en microsegundos.<\/p>\n<\/div>\n
\n
Mi consejo: utiliza la b\u00fasqueda clave\/valor siempre que puedas.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Obtener una entidad expandida por ID<\/h2>\n
\n
\n
Los datos pueden ser complejos y abarcar m\u00faltiples tablas (o m\u00faltiples documentos en el caso de Couchbase). Dependiendo de las herramientas que utilices, es posible que tengas alguna funcionalidad que pueda cargar entidades relacionadas.<\/p>\n<\/div>\n
\n
Por ejemplo, con Entity Framework, puede utilizar una directiva Incluya<\/code> para extraer entidades relacionadas, como se muestra en este GetPersonByIdExpandedAsync<\/code> ejemplo:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/personExpanded\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdExpandedAsync(int personId)\r\n{\r\n    var person = await _context.Persons\r\n        .Include(p => p.EmailAddresses)\r\n        .SingleOrDefaultAsync(p => p.BusinessEntityID == personId);\r\n\r\n    return Ok(person);\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Entre bastidores, Entity Framework puede generar un JOIN y\/o m\u00faltiples consultas SELECT para que esto suceda.<\/p>\n<\/div>\n
\n
Aqu\u00ed es donde cualquier O\/RM (no s\u00f3lo Entity Framework) puede ser peligroso. Aseg\u00farese de utilizar una herramienta como SQL Profiler para ver qu\u00e9 consultas se est\u00e1n ejecutando realmente.<\/p>\n<\/div>\n
\n\n\n\n
\n
Nota<\/div>\n<\/td>\n
Los O\/RM pueden ayudar, pero en un De SQL a NoSQL<\/a> en comparaci\u00f3n, es importante recordar que la incompatibilidad de impedancias es un problema mucho menor en el mundo NoSQL.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\n
Para el ejemplo de Couchbase, no estoy utilizando Entity Framework, pero en su lugar puedo utilizar el m\u00f3dulo Sintaxis NEST<\/a> que forma parte de las extensiones N1QL del est\u00e1ndar SQL. As\u00ed es como la versi\u00f3n Couchbase de GetPersonByIdExpandedAsync<\/code> parece:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/personExpanded\/{personId}\")]\r\npublic async Task<IActionResult> GetPersonByIdExpandedAsync(int personId)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var cluster = bucket.Cluster;\r\n    var personResult = await cluster.QueryAsync<Person>(@\"\r\n        SELECT p.*, EmailAddresses\r\n        FROM AdventureWorks2016.Person.Person p\r\n        NEST AdventureWorks2016.Person.EmailAddress EmailAddresses ON EmailAddresses.BusinessEntityID = p.BusinessEntityID\r\n        WHERE p.BusinessEntityID = $personId\",\r\n        new QueryOptions().Parameter(\"personId\", personId));\r\n    return Ok(await personResult.Rows.SingleOrDefaultAsync());\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
NEST es un tipo de JOIN que coloca los datos JOINed en un objeto JSON anidado. En lugar de utilizar un O\/RM para mapear los datos, estos datos pueden serializarse directamente en objetos C#.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
\n
Consulta de paginaci\u00f3n<\/h2>\n
\n
\n
Veamos un ejemplo en el que NO tenemos una \u00fanica clave para buscar un dato. Veamos un m\u00e9todo que devuelve una \"p\u00e1gina\" de resultados (quiz\u00e1s para rellenar una cuadr\u00edcula o lista de la interfaz de usuario).<\/p>\n<\/div>\n
\n
Paginaci\u00f3n en SQL Server<\/h3>\n
\n
Esta es la versi\u00f3n de SQL Server de GetPersonsPageAsync<\/code>:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/persons\/page\/{pageNum}\")]\r\npublic async Task<IActionResult> GetPersonsPageAsync(int pageNum)\r\n{\r\n    var pageSize = 10;\r\n    var personPage = await _context.Persons\r\n        .OrderBy(p => p.LastName)\r\n        .Skip(pageNum * pageSize)\r\n        .Take(pageSize)\r\n        .Select(p => new { p.BusinessEntityID, p.FirstName, p.LastName })\r\n        .ToListAsync();\r\n    return Ok(personPage);\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Con Entity Framework, OrderBy<\/code>, Saltar<\/code>y Toma<\/code> se utilizan normalmente para la paginaci\u00f3n. Si abrimos SQL Server Profiler, el SQL que esto genera se parece a esto:<\/p>\n<\/div>\n
\n
\n
exec sp_executesql N'SELECT [p].[BusinessEntityID], [p].[FirstName], [p].[LastName]\r\nFROM [Person].[Person] AS [p]\r\nORDER BY [p].[LastName]\r\nOFFSET @__p_0 ROWS FETCH NEXT @__p_0 ROWS ONLY',N'@__p_0 int',@__p_0=10<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
OFFSET ... ROWS FETCH NEXT ...<\/code> es la sintaxis que se utiliza aqu\u00ed para la paginaci\u00f3n.<\/p>\n<\/div>\n<\/div>\n
\n
Paging en Couchbase<\/h3>\n
\n
La sintaxis de paginaci\u00f3n siempre var\u00eda entre implementaciones SQL. Couchbase se inclina m\u00e1s hacia la sintaxis Oracle\/MySQL en este aspecto. Aqu\u00ed est\u00e1 la versi\u00f3n de Couchbase de GetPersonsPageAsync<\/code>:<\/p>\n<\/div>\n
\n
\n
[HttpGet(\"\/persons\/page\/{pageNum}\")]\r\npublic async Task<IActionResult> GetPersonsPageAsync(int pageNum)\r\n{\r\n    var pageSize = 10;\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var bucketName = bucket.Name;\r\n    var cluster = bucket.Cluster;\r\n\r\n    var personPage = await cluster.QueryAsync<Person>($@\"\r\n        SELECT p.LastName, p.BusinessEntityID, p.FirstName\r\n        FROM `{bucketName}`.Person.Person p\r\n        WHERE p.LastName IS NOT MISSING\r\n        ORDER BY p.LastName\r\n        LIMIT {pageSize} OFFSET {(pageNum * pageSize)}\r\n    \");\r\n\r\n    return Ok(await personPage.Rows.ToListAsync());\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
En este caso, L\u00cdMITE ... OFFSET ...<\/code> se est\u00e1 utilizando.<\/p>\n<\/div>\n
\n
Tambi\u00e9n quiero se\u00f1alar la WHERE p.Apellidos NO FALTA<\/code>. Dado que Couchbase es una base de datos NoSQL, el motor de consulta no puede asumir que Apellido<\/code> estar\u00e1 en todos los documentos, incluso con ORDER BY p.LastName<\/code>. Al a\u00f1adir este DONDE<\/code> la consulta sabe qu\u00e9 \u00edndice debe utilizar. Sin esto, la consulta tardar\u00e1 mucho m\u00e1s en ejecutarse.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
\n
Actualizaci\u00f3n con una transacci\u00f3n ACID<\/h2>\n
\n
\n
Con el modelo de estilo relacional que estamos utilizando tanto en SQL Server como en Couchbase para este ejemplo, las transacciones ACID ser\u00e1n importantes para ambas aplicaciones.<\/p>\n<\/div>\n
\n
En estos ejemplos, hay un PersonUpdateApi<\/code> que permitir\u00e1 al usuario actualizar ambos<\/strong> el nombre de una persona y su direcci\u00f3n de correo electr\u00f3nico. Dado que estos datos est\u00e1n en dos tablas\/filas separadas (SQL Server) o dos documentos separados (Couchbase), queremos que sea una operaci\u00f3n at\u00f3mica de todo o nada.<\/p>\n<\/div>\n
\n\n\n\n
\n
Nota<\/div>\n<\/td>\n
Se especifica un ID para ambas (para simplificar la API), ya que es posible (aunque poco frecuente en este conjunto de datos) que una persona tenga varias direcciones de correo electr\u00f3nico.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\n
ACID con Entity Framework<\/h3>\n
\n
A continuaci\u00f3n se muestra un ejemplo de una transacci\u00f3n ACID que utiliza Entity Framework para actualizar tanto una fila de datos de la tabla Persona como una fila de datos de la tabla EmailAddress.<\/p>\n<\/div>\n
\n
\n
[HttpPut(\"\/person\")]\r\npublic async Task<IActionResult> UpdatePurchaseOrderAsync(PersonUpdateApi personUpdateApi)\r\n{\r\n    var transaction = await _context.Database.BeginTransactionAsync();\r\n\r\n    try\r\n    {\r\n        \/\/ find the person\r\n        var person = await _context.Persons\r\n            .Include(p => p.EmailAddresses)\r\n            .SingleOrDefaultAsync(p => p.BusinessEntityID == personUpdateApi.PersonId);\r\n\r\n        \/\/ update name\r\n        person.FirstName = personUpdateApi.FirstName;\r\n        person.LastName = personUpdateApi.LastName;\r\n\r\n        \/\/ get the particular email address and update it\r\n        \/\/ if the supplied ID is invalid, this will throw an exception\r\n        var email = person.EmailAddresses.Single(e =>\r\n            e.EmailAddressID == personUpdateApi.EmailAddressId);\r\n        email.EmailAddress = personUpdateApi.EmailAddress;\r\n\r\n        await _context.SaveChangesAsync();\r\n\r\n        \/\/ commit transaction\r\n        await transaction.CommitAsync();\r\n\r\n        return Ok($\"Person {personUpdateApi.PersonId} name and email updated.\");\r\n    }\r\n    catch (Exception ex)\r\n    {\r\n        await transaction.RollbackAsync();\r\n        return BadRequest(\"Something went wrong, transaction rolled back\");\r\n    }\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
Tenga en cuenta las cuatro partes principales de una transacci\u00f3n:<\/p>\n<\/div>\n
\n
    \n
  1. Iniciar transacci\u00f3n (_context.Database.BeginTransactionAsync();<\/code>)<\/li>\n
  2. pruebe<\/code>\/captura<\/code><\/li>\n
  3. Transacci\u00f3n de compromiso (await transacci\u00f3n.CommitAsync();<\/code>)<\/li>\n
  4. Transacci\u00f3n de Rollback en el captura<\/code> (transacci\u00f3n.RollbackAsync();<\/code>)<\/li>\n<\/ol>\n<\/div>\n
    \n
    Esta es una caracter\u00edstica importante en la que la comparaci\u00f3n entre SQL y NoSQL ha cambiado en los \u00faltimos a\u00f1os. Con Couchbase, las transacciones ACID son ahora posibles.<\/p>\n<\/div>\n<\/div>\n
    \n
    ACID con una transacci\u00f3n Couchbase<\/h3>\n
    \n
    Con Couchbase, la API es ligeramente diferente, pero se siguen los mismos pasos:<\/p>\n<\/div>\n
    \n
    \n
    [HttpPut(\"\/person\")]\r\npublic async Task<IActionResult> UpdatePurchaseOrderAsync(PersonUpdateApi personUpdateApi)\r\n{\r\n    \/\/ setup bucket, cluster, and collections\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var scope = await bucket.ScopeAsync(\"Person\");\r\n    var personColl = await scope.CollectionAsync(\"Person\");\r\n    var emailColl = await scope.CollectionAsync(\"EmailAddress\");\r\n\r\n    \/\/ create transaction\r\n    var cluster = bucket.Cluster;\r\n    var transaction = Transactions.Create(cluster,\r\n        TransactionConfigBuilder.Create()\r\n            .DurabilityLevel(DurabilityLevel.None)\r\n            .Build());\r\n\r\n    try\r\n    {\r\n        await transaction.RunAsync(async (context) =>\r\n        {\r\n            \/\/ update person and email documents\r\n            \/\/ based on values passed in API object\r\n            var personKey = personUpdateApi.PersonId.ToString();\r\n            var emailKey = personKey + \"::\" + personUpdateApi.EmailAddressId.ToString();\r\n            var person = await context.GetAsync(personColl, personKey);\r\n            var email = await context.GetAsync(emailColl, emailKey);\r\n\r\n            var personDoc = person.ContentAs<dynamic>();\r\n            var emailDoc = email.ContentAs<dynamic>();\r\n\r\n            personDoc.FirstName = personUpdateApi.FirstName;\r\n            personDoc.LastName = personUpdateApi.LastName;\r\n            emailDoc.EmailAddress = personUpdateApi.EmailAddress;\r\n\r\n            await context.ReplaceAsync(person, personDoc);\r\n            await context.ReplaceAsync(email, emailDoc);\r\n        });\r\n        return Ok($\"Person {personUpdateApi.PersonId} name and email updated.\");\r\n    }\r\n    catch (Exception ex)\r\n    {\r\n        return BadRequest(\"Something went wrong, transaction rolled back.\");\r\n    }\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
    \n
    Los mismos pasos principales son:<\/p>\n<\/div>\n
    \n
      \n
    1. Iniciar transacci\u00f3n (transaction.RunAsync( ... )<\/code>)<\/li>\n
    2. pruebe<\/code>\/captura<\/code><\/li>\n
    3. Transacci\u00f3n de compromiso (impl\u00edcita, pero context.CommitAsync()<\/code> podr\u00eda utilizarse)<\/li>\n
    4. Transacci\u00f3n de reversi\u00f3n (de nuevo, impl\u00edcita, pero context.RollbackAsync()<\/code> ).<\/li>\n<\/ol>\n<\/div>\n
      \n
      En ambos casos, tenemos una transacci\u00f3n ACID. A diferencia de<\/strong> SQL Server, sin embargo, podemos m\u00e1s tarde<\/strong> optimizar y consolidar los datos en Couchbase para reducir la cantidad de transacciones ACID que necesitamos y aumentar el rendimiento.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
      \n
      Procedimientos almacenados: comparaci\u00f3n entre SQL y NoSQL<\/h2>\n
      \n
      \n
      Los procedimientos almacenados son un tema a veces controvertido. En general, pueden contener mucha funcionalidad y l\u00f3gica.<\/p>\n<\/div>\n
      \n
      Procedimiento almacenado en SQL Server<\/h3>\n
      \n
      He creado un procedimiento almacenado llamado \"ListSubcomponents\" (puede ver el archivo todos los detalles en GitHub<\/a>). Con Entity Framework, puede utilizar FromSqlRaw<\/code> para ejecutarlo y asignar los resultados a objetos C#. He creado un objeto C# pseudo-entidad llamado ListaSubcomponentes<\/code> que se utiliza s\u00f3lo para este sproc:<\/p>\n<\/div>\n
      \n
      \n
      \/\/ sproc example - see ExampleStoredProcedure.sql\r\n[HttpGet(\"\/getListSubcomponents\/{listPriceMin}\/{listPriceMax}\")]\r\npublic async Task<IActionResult> GetListSubcomponents(decimal listPriceMin, decimal listPriceMax)\r\n{\r\n    var listPriceMinParam = new SqlParameter(\"@ListPriceMin\", SqlDbType.Decimal) {Value = listPriceMin };\r\n    var listPriceMaxParam = new SqlParameter(\"@ListPriceMax\", SqlDbType.Decimal) {Value = listPriceMax };\r\n\r\n    var result = await _context.ListSubcomponents\r\n        .FromSqlRaw(\"EXECUTE dbo.ListSubcomponents @ListPriceMin, @ListPriceMax\", listPriceMinParam, listPriceMaxParam)\r\n        .ToListAsync();\r\n\r\n    return Ok(result);\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
      \n
      El procedimiento almacenado tiene dos par\u00e1metros.<\/p>\n<\/div>\n<\/div>\n
      \n
      Couchbase Funci\u00f3n definida por el usuario<\/h3>\n
      \n
      Couchbase no tiene nada llamado \"procedimiento almacenado\" (todav\u00eda), pero tiene algo llamado funci\u00f3n definida por el usuario (UDF) que tambi\u00e9n puede contener l\u00f3gica compleja cuando sea necesario.<\/p>\n<\/div>\n
      \n
      He creado una UDF llamada ListaSubcomponentes<\/code> (que tambi\u00e9n puede ver en GitHub<\/a>) que coincide con la funcionalidad del sproc de SQL Server.<\/p>\n<\/div>\n
      \n
      A continuaci\u00f3n se explica c\u00f3mo ejecutar esa UDF desde ASP.NET:<\/p>\n<\/div>\n
      \n
      \n
      \/\/ sproc example - see ExampleStoredProcedure.sql\r\n[HttpGet(\"\/getListSubcomponents\/{listPriceMin}\/{listPriceMax}\")]\r\npublic async Task<IActionResult> GetListSubcomponents(decimal listPriceMin, decimal listPriceMax)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync();\r\n    var cluster = bucket.Cluster;\r\n\r\n    var options = new QueryOptions();\r\n    options.Parameter(\"$listPriceMin\", listPriceMin);\r\n    options.Parameter(\"$listPriceMax\", listPriceMax);\r\n\r\n    var result = await cluster.QueryAsync<ListSubcomponent>(\r\n        \"SELECT l.* FROM ListSubcomponents($listPriceMin, $listPriceMax) l\", options);\r\n\r\n    return Ok(await result.Rows.ToListAsync());\r\n}<\/code><\/pre>\n<\/div>\n<\/div>\n
      \n
      Invocarlo en Couchbase con dos par\u00e1metros es muy similar a usar FromSqlRaw con Entity Framework.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
      \n
      Rendimiento - Comparaci\u00f3n de SQL con NoSQL<\/h2>\n
      \n
      \n
      Ahora que he convertido la aplicaci\u00f3n para utilizar Couchbase, \u00bfla nueva versi\u00f3n funciona al menos tan r\u00e1pido como la antigua versi\u00f3n de SQL Server?<\/p>\n<\/div>\n
      \n
      Es una pregunta complicada de responder porque:<\/p>\n<\/div>\n
      \n