31,014
edits
Lenguaje y Normas de Desarrollo: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 76: | Line 76: | ||
= Normas SQL = | = Normas SQL = | ||
= Tabla structura = | == Tabla structura == | ||
* Todas las tablas tienen prefijo para evitar conflictos de nombres. A día de hoy, el prefijo está determinado y no se puede cambiar. Su valor es <tt>llx_</tt>. Sin embargo, está pendiente de considerar, en una futura versión, el poder cambiarlo en el momento de la instalación. | * Todas las tablas tienen prefijo para evitar conflictos de nombres. A día de hoy, el prefijo está determinado y no se puede cambiar. Su valor es <tt>llx_</tt>. Sin embargo, está pendiente de considerar, en una futura versión, el poder cambiarlo en el momento de la instalación. | ||
| Line 88: | Line 88: | ||
- date para fecha | - date para fecha | ||
= Clave primaria = | == Clave primaria == | ||
La clave primaria de una tbla se llama <tt>rowid</tt>. | La clave primaria de una tbla se llama <tt>rowid</tt>. | ||
Hay unas pocas tablas que incumplen la norma ahora (ej [[Table llx_c_actioncomm]]), por razones históricas. Podrá ser estudiada una evolución para una próxima versión. | Hay unas pocas tablas que incumplen la norma ahora (ej [[Table llx_c_actioncomm]]), por razones históricas. Podrá ser estudiada una evolución para una próxima versión. | ||
= Clave secundaria = | == Clave secundaria == | ||
El nombre de una clave secundaria empieza con el prefijo <tt>fk_</tt> seguido por el nombre de la tabla vinculada (necesario para evitar duplicaciones globales en la base de datos, problemáticas en algunos RDBMS como postgresql), seguido del campo vinculado (para permitir diferentes claves secundarias en la misma tabla). | El nombre de una clave secundaria empieza con el prefijo <tt>fk_</tt> seguido por el nombre de la tabla vinculada (necesario para evitar duplicaciones globales en la base de datos, problemáticas en algunos RDBMS como postgresql), seguido del campo vinculado (para permitir diferentes claves secundarias en la misma tabla). | ||
| Line 99: | Line 99: | ||
fk_facture_fourn_fk_soc | fk_facture_fourn_fk_soc | ||
= Clave alternativa = | == Clave alternativa == | ||
A veces no sólamente la clave primaria debe ser única. Por lo tanto, podemos añadir un índice de clave única alternativa. Este índice es llamado por un nombre que comienza con el prefijo <tt>uk_</tt> seguido por el nombre de la tabla (necesario para evitar la duplicación de índeces globales en la base de datos, problemáticos en algunos DBMS como postgresql) y de un sufijo que caracterice a la clave (para permitir múltiples índices en una sola tabla). | A veces no sólamente la clave primaria debe ser única. Por lo tanto, podemos añadir un índice de clave única alternativa. Este índice es llamado por un nombre que comienza con el prefijo <tt>uk_</tt> seguido por el nombre de la tabla (necesario para evitar la duplicación de índeces globales en la base de datos, problemáticos en algunos DBMS como postgresql) y de un sufijo que caracterice a la clave (para permitir múltiples índices en una sola tabla). | ||
| Line 106: | Line 106: | ||
uk_societe_code_client | uk_societe_code_client | ||
= Indices de rendimiento = | == Indices de rendimiento == | ||
Algunos campos se utilizan a menudo como un criterio para la búsqueda, clasificación o afiliación. Conviene en este caso, poner un índice de rendimiento. Tales índices se llamarán con un prefijo <tt>idx_</tt> seguidos del nombre de la tabla y el nombre del campo en el que el índice trabaja. | Algunos campos se utilizan a menudo como un criterio para la búsqueda, clasificación o afiliación. Conviene en este caso, poner un índice de rendimiento. Tales índices se llamarán con un prefijo <tt>idx_</tt> seguidos del nombre de la tabla y el nombre del campo en el que el índice trabaja. | ||
| Line 112: | Line 112: | ||
idx_societe_user_creat | idx_societe_user_creat | ||
== Formato de fichero DDL == | |||
Los ficheros que contienen la definición de la estructura de la base de datos (DDL) deben de estar repartidos en dos tablas: | Los ficheros que contienen la definición de la estructura de la base de datos (DDL) deben de estar repartidos en dos tablas: | ||
* Cada tabla se define en su propio archivo cuyo nombre es <tt>llx_''mitabla''.sql</tt> | * Cada tabla se define en su propio archivo cuyo nombre es <tt>llx_''mitabla''.sql</tt> | ||
| Line 176: | Line 176: | ||
</source> | </source> | ||
= SQL Coding rules = | == SQL Coding rules == | ||
* Uso de alias / nombres de los campos | * Uso de alias / nombres de los campos | ||
Dentro de los selects pueden utilizar alias para simplificar la redacción de las consultas: | Dentro de los selects pueden utilizar alias para simplificar la redacción de las consultas: | ||
| Line 202: | Line 202: | ||
* las funciones NOW, SYSDATE ó IFNULL están prohibidas en las órdenes de SQL. Si se necesita indicar la fecha del momento en un campo, el valor debe provenir de PHP y no del motor de la base de datos. Esto además de ofrecer una mejor portabilidad del código, también permite una gestión correcta de la zona horaria. | * las funciones NOW, SYSDATE ó IFNULL están prohibidas en las órdenes de SQL. Si se necesita indicar la fecha del momento en un campo, el valor debe provenir de PHP y no del motor de la base de datos. Esto además de ofrecer una mejor portabilidad del código, también permite una gestión correcta de la zona horaria. | ||
= Particularidades de MySQL = | == Particularidades de MySQL == | ||
* Las tablas deben de estar en formato InnoDB. | * Las tablas deben de estar en formato InnoDB. | ||
| Line 213: | Line 213: | ||
</source> | </source> | ||
= Particularidades de PostgreSQL = | == Particularidades de PostgreSQL == | ||
Sólo los archivos de MySQL deben mantenerse. | Sólo los archivos de MySQL deben mantenerse. | ||
Los archivos para otras bases de datos se convierten "al vuelo" por el gestor de la base de datos. | Los archivos para otras bases de datos se convierten "al vuelo" por el gestor de la base de datos. | ||