Diferencias

Muestra las diferencias entre dos versiones de la página.

--- db:sql [2010/07/10 15:24]
alfred creado
+++ db:sql [2020/05/09 09:25] (actual)
@@ Línea 97: / Línea 97: @@
 ==== Eliminar ====
-==== Consulta de datos ====
+===== Consulta de datos =====
 ==== Selects ====
@@ Línea 182: / Línea 183: @@
   * **sum** devuelve la suma de los valores de un campo numérico en una consulta:
 <code sql>select ciudad.nombre, sum(pueblo.hab) from pueblo, ciudad where (pueblo.id_ciudad = ciudad.id) group by (ciudad.nombre);</code>
 ===== Notas =====
+==== Tips ====
 === Insertar los datos de un select ===
 Teniendo dos tablas:
@@ Línea 195: / Línea 198: @@
 </code>
+==== Errores comunes ====
+  * **No usar correctamente los índices**;  Deberían de tener índices obligatoriamente las foreign keys, los campos utilizados en WHERE...
+  * **No apoyarse en la integridad referencial**, si la DB lo permite (por ejemplo las foreign keys) esta debería ser usada siempre.
+  * **Utilizar claves naturales**, estas son claves únicas del mundo real (código de la seguridad social, código de productos...) pero no tienen sentido en la DB, se inventaron para identificar el elemento fuera de la DB y es preferible utilizar campos de autoincremento.
+  * **Escribir consultas que requieran DISTINCT para funcionar**, no es que la clausula DISTINCT sea incorrecta es que apunta a que pueden haber datos duplicados en la base de datos.
+  * **Preferir agregación sobre joins**, las operaciones de agregaciones (como GROUP BY) son sumamente lentas comparadas con joins. Un ejemplo:
+<code>
+SELECT userid
+FROM userrole
+WHERE roleid IN (1, 2, 3)
+GROUP by userid
+HAVING COUNT(1) = 3
+Query time: 0.312s
+------------------------------------------------------
+SELECT t1.userid
+FROM userrole t1
+JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
+JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
+AND t1.roleid = 1
+Query time: 0.016s
+</code>
+  * **No securizar las consultas**, el usuario podría introducir código malicioso.
+  * **No utilizar //prepared statements//**, estos son consultas compiladas en la DB a las que les pasas parámetros (por ejemplo, según la plataforma, utilizar ''SELECT * FROM users WHERE username = ?'' o ''SELECT * FROM users WHERE username = :username'' en vez de ''SELECT * FROM users WHERE username = 'bob'''). Cada vez que una DB moderna recibe una nueva consulta la ha de compilar, si la consulta ya "la ha visto antes" podrá cachear la ejecución además de que puede ser importante a la hora de realizar estadisticas sobre las consultas utilizadas y evita el código malicioso.
+  * **No realizar analisis de rendimientos**, como el de las consultas anteriores.
+  * **Utilizar condiciones con OR en consultas**, las condiciones AND restingen los datos mientras que los OR los hacen crecer y esto desfavorece al motor de la DB.
+<code>
+Bad:
+... WHERE a = 2 OR a = 5 OR a = 11
+Better:
+... WHERE a IN (2, 5, 11)
+</code>
+  * **No simplificar consultas complejas mediante vistas**, en las DB que soportan vistas es de gran ayuda utilizarlas
+<code>
+Model:
+    * Party: people and organisations;
+    * Party Role: things those parties did eg Employer and Employer;
+    * Party Role Relationship: how those roles related to each other.
+Example:
+    * Ted is a Person, being a subtype of Party;
+    * Ted has many roles, one of which is Employee;
+    * Intel is an organisation, being a subtype of a Party;
+    * Intel has many roles, one of which is Employer;
+    * Intel employs Ted, meaning there is a relationship between their respective roles.
+So there are five tables joined to link Ted to his employer. You assume all employees are Persons (not organisations) and provide this helper view:
+CREATE VIEW vw_employee AS
+SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
+FROM person p
+JOIN party py ON py.id = p.id
+JOIN party_role child ON p.id = child.party_id
+JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
+JOIN party_role parent ON parent.id = prr.parent_id = parent.id
+JOIN party p2 ON parent.party_id = p2.id
+And suddenly you have a very simple view of the data you want but on a highly flexible data model.
+</code>
+  * **Utilizar //exclusive arcs//**, estos consisten en crear una tabla con dos o más foreign keys de las cuales una pueda ser not-null, esto hace que sea más complejo mantener la integridad referencial.
+  * **No normalizar suficiente**, la normalización consiste en optimizar el diseño de la DB y organizar correctamente los datos en tablas.
+  * **Normalizar demasiado**. Para cuatro conceptos no deberías tener once tablas.
+Sacado de [[http://stackoverflow.com/questions/621884/database-development-mistakes-made-by-app-developers/621891#621891|Stack Overflow]]

Programming

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página