{"id":13618,"date":"2022-08-02T09:46:48","date_gmt":"2022-08-02T16:46:48","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=13618"},"modified":"2025-06-13T20:56:42","modified_gmt":"2025-06-14T03:56:42","slug":"asp-net-crud-nosql-part-5","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/asp-net-crud-nosql-part-5\/","title":{"rendered":"ASP.NET Core CRUD con NoSQL: Parte 5"},"content":{"rendered":"

Esta serie de ASP.NET Core CRUD est\u00e1 llegando a su fin. Hemos cubierto <\/span>configuraci\u00f3n (parte 1)<\/span><\/a>, <\/span>lectura con SQL++ (parte 2)<\/span><\/a>, <\/span>lectura con clave-valor (parte 3)<\/span><\/a>y <\/span>crear\/actualizar (parte 4)<\/span><\/a>. En este \u00faltimo post, veremos la D<\/strong> en CRUD<\/strong>: borrar<\/em>.<\/span><\/p>\n

Borrado con SQL++ o clave-valor<\/b><\/h2>\n

Espero que est\u00e9s notando un patr\u00f3n. Al igual que con la lectura, creaci\u00f3n y actualizaci\u00f3n, tienes m\u00faltiples caminos para borrar. Puedes usar un SQL++ <\/span>BORRAR<\/span><\/em> declaraci\u00f3n:<\/span><\/p>\n

DELETE FROM demo._default.wishlist w\r\nWHERE META(w).id = \"1c3de2e7-70ea-4ee2-803b-425bbf6251cb\"<\/pre>\n
Tambi\u00e9n puede utilizar una operaci\u00f3n de eliminaci\u00f3n de clave-valor (tambi\u00e9n conocida como \"Eliminar<\/em>“):<\/span><\/p>\n
await collection.RemoveAsync(\"1c3de2e7-70ea-4ee2-803b-425bbf6251cb\");<\/pre>\n
Y como antes, aqu\u00ed tienes unas pautas muy parecidas para ayudarte a decidir cu\u00e1l utilizar:<\/span><\/p>\n\n\n\n\n\n\n
Caso pr\u00e1ctico<\/strong><\/td>\n\u00bfClave-valor?<\/strong><\/td>\n\u00bfPor qu\u00e9 s\u00ed o por qu\u00e9 no?<\/strong><\/td>\n<\/tr>\n
Eliminar un usuario con clave \"73892\"<\/span><\/td>\nS\u00ed<\/span><\/td>\nAcceso directo<\/span><\/td>\n<\/tr>\n
Eliminar un grupo de usuarios con las claves \"73892\", \"47212\" y \"90491\".<\/span><\/td>\nS\u00ed<\/span><\/td>\nEsto puede requerir m\u00faltiples operaciones clave-valor, pero a\u00fan as\u00ed puede ser m\u00e1s r\u00e1pido que utilizar un SQL <\/span>SUPRIMIR ... DONDE ... EN<\/span><\/em> consulta.<\/span><\/td>\n<\/tr>\n
Borrar todos los usuarios de \"Ohio\"<\/span><\/td>\nNo<\/span><\/td>\nEl estado del usuario es probablemente un atributo \"secundario\", no una clave (varios usuarios pueden ser de Ohio). Este es un buen caso de uso para un SQL++. <\/span>BORRAR<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Un punto final de eliminaci\u00f3n para ASP.NET Core<\/b><\/h2>\n
Con esto en mente, crea un punto final de borrado como este:<\/span><\/p>\n
[HttpDelete]\r\n[Route(\"api\/delete\")]\r\npublic async Task Delete(Guid id)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync(\"demo\");\r\n    var collection = await bucket.CollectionAsync(\"wishlist\");\r\n\r\n    await collection.RemoveAsync(id.ToString());\r\n\r\n    return Ok(new { success = true });\r\n}<\/pre>\n
Pruebe este endpoint con OpenAPI \/ Swagger, y se comportar\u00e1 como cabr\u00eda esperar.<\/span><\/p>\n
\"Swagger<\/p>\n
\u00bfDeber\u00eda borrarlo?<\/b><\/h2>\n
En muchos casos de uso, es posible que no desee <\/span>en realidad<\/b> borrar datos. Puede que quiera hacer algo llamado borrado \"suave\". Esto implica mover o marcar los datos de tal forma que sigan existiendo en la base de datos, pero ya no se muestren al usuario final. Esto tiene la ventaja de que se pueden descubrir, recuperar y notificar.<\/span><\/p>\n
Tambi\u00e9n es una gran oportunidad para mostrar la flexibilidad de una base de datos JSON NoSQL.<\/span><\/p>\n
Borrado suave<\/b><\/h2>\n
Introduzcamos un campo \"eliminado\" en los elementos de la lista de deseos. Este campo contendr\u00e1 la fecha\/hora en que se elimin\u00f3 el art\u00edculo. Si este campo existe, el resto del endpoint deber\u00eda considerar que este art\u00edculo ha sido eliminado. Sin embargo, si lo necesitamos, a\u00fan podemos consultarlo, informar sobre \u00e9l y recuperarlo.<\/span><\/p>\n
En una base de datos relacional, esto requerir\u00eda probablemente un <\/span>ALTERAR<\/span><\/em>. Dependiendo del tama\u00f1o de tus datos, podr\u00eda requerir alg\u00fan tiempo de inactividad, o posiblemente un mont\u00f3n de valores NULL. En una base de datos JSON, no necesitamos decirle nada a la base de datos sobre un nuevo campo.<\/span><\/p>\n
Utilicemos el <\/span>API de subdocumentos<\/span><\/a> para a\u00f1adir un \"suprimido<\/em>\"al documento. Subdocumento significa que s\u00f3lo operaremos sobre un <\/span>porci\u00f3n<\/b> del JSON, y dejar el resto solo.<\/span><\/p>\n
[HttpDelete]\r\n[Route(\"api\/softDelete\")]\r\npublic async Task SoftDelete(Guid id)\r\n{\r\n    var bucket = await _bucketProvider.GetBucketAsync(\"demo\");\r\n    var collection = await bucket.CollectionAsync(\"wishlist\");\r\n\r\n    await collection.MutateInAsync(id.ToString(),\r\n        options => options.Upsert(\"eliminado\", DateTime.Now));\r\n\r\n    return Ok(new { \u00e9xito = verdadero });\r\n}<\/pre>\n
(Aseg\u00farese de que <\/span>utilizando Couchbase.KeyValue;<\/em><\/span> est\u00e1 en la parte superior de su GiftsController<\/em> archivo).<\/span><\/p>\n
Este c\u00f3digo env\u00eda una orden a Couchbase: <\/span>para el documento con tal y tal ID, upsert un campo llamado \"suprimido<\/em>\"y dale como valor la fecha\/hora actual<\/span>.<\/span><\/p>\n
F\u00edjate en que con el subdocumento no tenemos que cargar primero el documento existente y no tenemos que enviar todo el documento modificado de vuelta a trav\u00e9s del cable.<\/span><\/p>\n
Datos borrados<\/b><\/h2>\n
El resultado final ser\u00e1 un documento con este aspecto:<\/span><\/p>\n
{\r\n  \"nombre\": \"Marco de fotos digital\",\r\n  \"deleted\": \"2022-04-21T11:05:26.1766248-04:00\"\r\n}<\/pre>\n
Los dem\u00e1s documentos de mi lista de deseos s\u00ed <\/span>no<\/b> tener un <\/span>suprimido<\/span> campo. Siguen pareciendo:<\/span><\/p>\n
{\r\n  \"nombre\": \"Camiseta Skyline Chili 2XL\"\r\n}<\/pre>\n
y<\/span><\/p>\n
{\r\n  \"nombre\": \"Joey Votto jersey\"\r\n}<\/pre>\n
Tenga en cuenta que no tienen <\/span>\"suprimido\": null<\/span><\/em> campo; no tienen <\/span>“suprimido<\/em>“<\/span> campo en absoluto.<\/span><\/p>\n
Borrado suave SELECT<\/b><\/h2>\n
Los datos son <\/span>marcado<\/b> como eliminado, pero sigue en la base de datos. Tenemos que modificar el <\/span>GetAll<\/span><\/em> punto final (<\/span>consulte la parte 2 para obtener m\u00e1s informaci\u00f3n <\/span>GetAll<\/span><\/a>) para tenerlo en cuenta:<\/span><\/p>\n
SELECT META(w).id, w.*\r\nFROM demo._default.wishlist w\r\nWHERE w.deleted IS MISSING<\/pre>\n
Aqu\u00ed he introducido algo m\u00e1s de sintaxis SQL++: <\/span>FALTA<\/span><\/em>. Se trata de un concepto que no existe en las bases de datos relacionales. En relacional, cualquier columna especificada en la consulta debe estar definida y debe tener un valor (incluso si es nulo). Con una base de datos de documentos JSON NoSQL, no existe tal restricci\u00f3n.<\/span><\/p>\n
Mejorar el \u00edndice<\/b><\/h2>\n
Un \u00faltimo punto a tratar es la indexaci\u00f3n. En <\/span>parte 2<\/span><\/a>hemos creado un \u00edndice primario para empezar. Sin embargo, ese \u00edndice rara vez ser\u00e1 el m\u00e1s eficiente. <\/span>Creaci\u00f3n y ajuste de \u00edndices<\/span><\/a> es un tema profundo, como lo es en el mundo de las bases de datos relacionales.<\/span><\/p>\n
Afortunadamente, Couchbase Capella tiene incorporado un <\/span>Aconsejar<\/strong> herramienta<\/span><\/a> que puede recomendar mejores \u00edndices. Haga clic en Aconsejar<\/strong>\u00a0en el Query Workbench (o puede utilizar <\/span>CONSEJO<\/span><\/em> sintaxis).<\/span><\/p>\n
\"Index<\/p>\n
En este caso, da la siguiente recomendaci\u00f3n:<\/span><\/p>\n
\"\u00edndices_recomendados\": {\r\n          \"indexes\": [\r\n            {\r\n              \"index_statement\": \"CREATE INDEX adv_deletedISMISSING ON `default`:`demo`.`_default`.`wishlist`(`deleted` IS MISSING) WHERE `deleted` IS MISSING\",\r\n              \"index_statement_relative\": \"CREATE INDEX adv_deletedISMISSING ON `wishlist`(`deleted` IS MISSING) WHERE `deleted` IS MISSING\",\r\n              \"keyspace_alias\": \"wishlist_w\",\r\n              \"query_context\": \"default:demo._default\",\r\n              \"recommendeding_rule\": \"Las claves del \u00edndice siguen el orden de los tipos de predicado: 2. igualdad\/nulo\/falta\".\r\n            }\r\n          ]\r\n        }<\/pre>\n
En el caso de nuestra peque\u00f1\u00edsima cantidad de datos de listas de deseos, probablemente no merezca la pena crear este \u00edndice. Sin embargo, si estuvi\u00e9ramos gestionando las listas de deseos de todo un sitio de comercio electr\u00f3nico (por ejemplo), este \u00edndice ser\u00eda un buen punto de partida.<\/span><\/p>\n
El fin del CRUD<\/b><\/h2>\n
Hemos llegado al final de la creaci\u00f3n de una aplicaci\u00f3n ASP.NET Core CRUD muy sencilla con Couchbase. La superficie final de la API tiene este aspecto:<\/span><\/p>\n
\"Full<\/p>\n
Aqu\u00ed tienes un desglose de los conceptos de esta serie, con enlaces a documentaci\u00f3n para profundizar:<\/span><\/p>\n