- Este debate está vacío.
-
Entradas
-
Buenas. Antes que nada felicitaciones a todo el equipo de desarrollo por el nuevo release; es muy bueno ver los avances.
Bueno, a lo que iba es que mirando las novedades me puse a mirar las tablas nuevas desde el pgAdmin y descubrí (bah, pgAdmin me mostró una advertencia) que las tablas relacionados a la facturación electrónica:
ad_electronicinvoiceformat
ad_electronicinvoiceformathdr
ad_electronicinvoiceformatline
e_electronicinvoice
e_electronicinvoiceline
e_electronicinvoiceref
NO tiene definidas claves primarias a nivel de sql y tampoco claves foraneas entre si ( digamos, ad_electronicinvoiceformatline.ad_electronicinvoiceformathdr_id debería ser una referncia foranea a ad_electronicinvoiceformathdr.ad_electronicinvoiceformathdr_id ). En el caso de las tablas relacionadas a formatos, más allá de que a nivel de sql se pueden caer en inconsistencias, no lo veo tan grave ya que me da la sensación que son una tablas con pocas entradas.
Ahora, bien, las tablas e_xxxxxx me parece que van a ser tablas con más datos y referencias más a menudo.
El tema de poner claves primarias y foraneas no es solo por un cuestión de integridad; postgres ante este tipo de restricciones crea implicitamente indices de búsqueda. Esto es de particular importancia para las claves primarias, de lo contrario un simple select usando un where Id=algo, postgres necesariamente va tener que recorrer TODA la tabla y además lo va a hacer de manera secuencial! (no va a parar al encontrar la primer fila que satisfaga al where, ya que no sabe esa columna es una clave primaria).La versión que instale el instalador automatico “todo en uno”, con localización Argentina (dicho sea de paso, no tuve ningún problema con la instalación salvo que tuve que escoger otro nombre de base de datos y otro dir de instalación ya que tengo la versión 9.10 también instalada).
Saludos.
- Debes estar registrado para responder a este debate.
