Developer’s fourteen steps to deal with SQL

Developer’s fourteen steps to deal with SQL
  1. Do not worry about tables yet. Undoubtedly you are creating a database and databases (at least relational ones) are mainly composed of tables, which in turn are built using rows and columns (records and attributes, for those who have the knowledge).
  2. Concern about the relationships between entities. Your first goal is to map the relationships that different business objects will have. It is the logical schema. The physical model is the hands-on implementation. Do not confuse nor mix up them.

Requirements are difficult to obtain. A talented business analyst at this point, would be a stroke of luck.

  1. Prepare yourself to confront a war on your own, dedicating yourself to quality standardization. Most databases are a wastage since their designers are lazy and just want to get something. You can always fix it later. Yes, of course.
  2. When it comes to write the tables, focus on the queries and the table types (zip codes, states, product categories, etc.). You’ll need them for outside key relationships in actual tables. In addition, it will provide you warm up before reaching the main transactional tables.
  3. General rule: do not store data that can be inferred from other fields. If you know the date of birth and the start date, you will also know the age on the start date. Do not include this age in the table.
  4. No NULL needed. A NULL value (zero) represents an undefined attribute of an identity. If an entity may have or not a specific attribute, then it needs to be manipulated using a cross tab.
  5. NULL contradictory values are useful for identifying attributes that have not yet been completed by users. This is particularly useful when a user needs to select a preset value to determine the implementation of the suitable trading rules. In case 2, how would you design an address table where Address1 was completed and Address2 was not needed, but if Address2 were completed it should fit the field trading rules? Try a third standard form in an international direction. It can probably be completed, but note the difficulty of the data restructuring in a meaningful way.
  6. NULL / NOT NULL. Browse database forums, and you will confirm that it is a common subject in which there are supporters of the advantages and disadvantages of each one.

Nevertheless, everyone agrees that you should never allow NULL values in key variables. These are the fields used to identify a single record,  such as the customer’s identification number.

  1. NULL states that you should use the NULL values without restrictions in the other fields. For example, it is not mandatory that customers have a cell phone, or provide you the number. Using a NULL value and nothing but NULL is the most efficient way to record that there isn’t a cell phone available.
  2. Use a proper naming convention. Place the invoices in a table called invoice. The products go in product. The cross table would be invoiceProduct, or productinvoice, depending on which table is the accurate relationship center.
  3. If you’re going to make replications or send records, try setting it up while you’re developing it to see how it operates.
  4. Internal joins are great, but will probably also have several SURPLUS EXTERNAL JOINS statements with which it could work. Get used to the various statements of joins (except UNION).
  5. If you have to deal with a legacy application, build your schema regardless of that (not even look at it). Focus on relationships and trading rules you are trying to execute, but you could distract yourself if you look at the way someone else configured it. Refer to step # 4.
  6. It is difficult to migrate from a legacy system to a more suitable model with proper normalization, but it can be simplified to a certain extent if temporary tables are used for imports. In addition, keep index on legacy IDs so people can search for them.


Los 14 pasos de un desarrollador para lidiar con SQL

1 – No te preocupes por las tablas aún. Obviamente estás creando una base de datos, y las bases de datos (al menos las relacionales) están compuestas principalmente por tablas, que a su vez están compuestas de filas y columnas (registros y atributos, para los que conocen).

2 – Preocúpate por las relaciones entre entidades. Tu primera meta es hacer un mapa de las relaciones que tendrán los distintos objetos comerciales. Es la parte de modelado lógico. El modelo físico es la implementación práctica. No confundas ni combines los dos.

Los requisitos son difíciles de conseguir y dolorosos. Un analista comercial talentoso en esos momentos sería un regalo del cielo.

3 – Prepárate para librar una guerra en solitario, dedicándote solo tú a la normalización de calidad. La mayoría de las bases de datos son un desperdicio porque sus diseñadores son perezosos y sólo quieren conseguir algo. Siempre se puede arreglar más adelante. Sí, claro.

4 – Una vez que llegue el momento de escribir las tablas, concéntrate en las búsquedas y en los tipos de tablas (códigos postales, estados, categorías de productos, etc.). Las necesitarás para relaciones clave exteriores en las tablas verdaderas. Además, te dará un precalentamiento antes de llegar a las tablas transaccionales centrales.

5 – Como regla general: no almacenes datos que puedan inferirse de otros campos. Si conoces la fecha de nacimiento y la fecha de inicio, también conocerás la edad en la fecha de inicio; no incluyas esta edad en la tabla.

6 – Ningún NULL. Un valor NULL (nulo) representa un atributo indefinido de una identidad. Si una entidad puede tener o no un atributo en particular, entonces necesita ser manipulada mediante una tabla cruzada.

7 – Los valores NULL contradictorios son útiles en sí mismos para identificar atributos que aún no hayan sido completados por los usuarios. Esto es particularmente útil cuando un usuario necesita seleccionar un valor predeterminado para determinar la aplicación de las reglas comerciales adecuadas. En el caso 2, ¿cómo diseñarías una tabla de direcciones en la que Dirección1 fuera completada y Dirección2 no fuera necesaria, pero si Dirección2 fuera completada debería conformarse a las reglas comerciales del campo? Seguro, podrías poner como predeterminado un espacio en blanco, ¿pero es mejor que saber que el usuario no editó el campo? Prueba con un tercer formulario normal en una dirección internacional… Probablemente se pueda hacer, pero observa la complejidad de la reestructuración de los datos en una forma significativa.

8 – NULL/NOT NULL Revisa los foros de bases de datos, y verás que es un tema popular en el que hay defensores de las ventajas y desventajas de cada uno.

Sin embargo, todos coinciden en que nunca deberías permitir valores NULL en variables clave. Estos son los campos que se usan para identificar un registro único, como puede ser el número de identificación del cliente.

La escuela NULL dice que deberías usar libremente los valores NULL en los demás campos. Por ejemplo, no es obligatorio que los clientes tengan un teléfono celular, ni que te den el número. Usar un valor NULL y nada más que NULL es la manera más eficiente de registrar que no hay un teléfono celular disponible.

Si es realmente importante saber por qué no hay un valor, lo mejor es introducir una variable nueva que indique el motivo, en vez de introducir algún código extravagante para almacenar en lugar del número de teléfono celular. Evita agregar campos como esos, porque a) el cliente tampoco está obligado a decirte el motivo por el que no te da su número de teléfono celular, ni es una buena pregunta, y tampoco te dirá espontáneamente la razón, y b) nunca nadie lo mirará justamente debido a a). Las variables faltantes sólo desperdician tiempo.

Ten cuidado con las variables sí/no (booleanas), ya que en general no pueden contener un NULL. Por lo tanto, suelen contener información inútil, como o era republicano, o se rehusó a contestar.

9 – Familiarízate con las tablas cruzadas (muchos a muchos). Las usarás en todas partes, si estás haciendo bien las cosas. Un ejemplo sería una base de datos de una escuela en la que hay una tabla para los maestros y otra para los estudiantes. Los estudiantes tienen más de un maestro, y los maestros tienen más de un estudiante, por lo que la tabla cruzada, aparte de las de ‘maestros’ y ‘alumnos’, tendría dos columnas con claves externas apuntando a las dos. La clave primaria sería la combinación de esas dos.

10 – Usa una buena convención para los nombres. Coloca las facturas en una tabla llamada factura. Los productos van en producto. La tabla cruzada sería facturaProducto, o productoFactura, dependiendo de cuál tabla sea el verdadero centro de la relación.

11 – Si vas a hacer replicaciones o envíos de registros, prueba configurar mientras lo desarrollas para ver cómo funciona.

12 – Las uniones internas son muy buenas, pero probablemente también haya muchas declaraciones de UNIONES EXTERNAS SOBRANTES con las que podría funcionar. Acostúmbrate a las distintas declaraciones de uniones (excepto UNION).

13 – Si tienes que lidiar con una aplicación heredada, construye tu esquema independientemente de eso (ni siquiera lo mires). Concéntrate en las reglas y relaciones comerciales que intentas ejecutar, pero podrías distraerte si miras la forma en la que alguien más la configuró. Refiérete al paso #4.

14 – Es difícil migrar desde un sistema de herencia hacia un modelo más ajustado con una normalización apropiada, pero se puede facilitar un poco si se usan tablas temporales para las importaciones. Además, conserva índices en los ID de herencia para que la gente pueda buscarlos.

Share This