| gx-l |
| Gabriel Medina | |
Hola Amigos,
*Me dice un DBA:* GeneXus lo hace mal, hace un Index *Unique* en vez de
hacer una Constraint
Y además He creado un índice *unique *que incluye una FK, y le hace un Drop
al índice previo de la FK, cosa que me sorprendió gratamente, pero mi *amigo
DBA *me dice que Gx comete *UN ERROR al *hacer un DROP de un índice
ForeignKey que es óptimo en las búsquedas cuando es de una sola columna.
*CASO:*
*EmpresaTRN:*
*EmpresaId**
*EmpresaNombre*
*DeparatamentoTRN:*
*DepartamentoId**
*DepartamentoNombre*
*DepartamentoCodigo *
*EmpresaId*
-- Como necesito que NO se dupliquen los códigos de departamento dentro de
cada empresa hice un índice
*UNIQUE Compuesto xEmpresaId*DepartamentoCodigo**
Por esta razón Gx borró el indice de la FK x EmpresaId, y dejo un sólo
indice porque con eso *basta*, y a mi me gustó, pero mi amigo el *DBA, *me
dice que está mál que eso no va a ser performante.
-----
Yo estoy conforme y *de acuerdo* con lo que GeneXus hace, alguno de los
participantes del foro podría darme argumentos para convencer al *DBA que
GeneXus hizo lo correcto?*
Muchas gracias por la ayuda!
*TODA respuesta será muy bienvenida y usada -en lo posible- para defender a
mi querido GeneXus.*
--
Saludos,
gab
@gxsoft
-----------------------------------------
Para Suscribirse/Desuscribirse:
http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,1
Por consultas owner-gx-l@gxtech.com.uy |
|
|
| | |
leandro79337933 | | |
Hola Gab, hay que ver como es "bajo el capó" en otros RDBMSes, pero en SQL
Server no hay diferencias significativas.
De aqui (versiones SQL viejas):
https://docs.microsoft.com/en-us/previous-versions/sql/legacy/aa224827(v=sql.80)?redirectedfrom=MSDN
podemos concluir lo siguiente:
"""
In summary, we can safely conclude that there's no practical difference
between a unique constraint and a unique index other than the fact that the
unique constraint is also listed as a constraint object in the database.
Since a unique constraint can't be disabled, having the status of a
constraint doesn't give the unique constraint any additional behavior
beyond a unique index. However, there are several index creation options
that aren't available to the ALTER TABLE command that creates a unique
constraint.
"""
y de aqui (versiones SQL más nuevas):
https://docs.microsoft.com/en-us/sql/relational-databases/indexes/create-unique-indexes?redirectedfrom=MSDN&view=sql-server-ver15
masomenos lo mismo:
"""
There are no significant differences between creating a UNIQUE constraint
and creating a unique index that is independent of a constraint. Data
validation occurs in the same manner, and the query optimizer does not
differentiate between a unique index created by a constraint or manually
created. However, creating a UNIQUE constraint on the column makes the
objective of the index clear.
"""
Por ultimo, el DROP de la FK EmpresaId en la tabla DepartamentoTRN es,
podríamos decir, *correcto*. Funcionalmente necesitas el constraint UNIQUE
por EmpresaId + DepartamentoCodigo. Hasta cierto punto es válido lo que
indica el DBA que es más óptimo un índice de 1 sola columna. Pero si no se
elimina el índice EmpresaId entonces quedarían 2 índices, uno para la FK y
otro para el UNIQUE. Esto degradaria más la performance durante los
inserts/updates/deletes ya que el motor tiene que mantener 2 índices en
lugar de uno.
Slds
On Thu, Jan 14, 2021 at 7:09 PM Gabriel Medina |
|
|
leandro79337933 | | |
Hola Gab, recomendación? bueno, como DBA mi función es administrar las
bases de datos, tal como indican sus siglas. Obviamente estoy al servicio
de los desarrolladores cuando necesitan asesoramiento, consejos o
experiencias sobre el funcionamiento interno de un motor de bd. Jamás
juzgaría algo sin saber los motivos que llevaron a esa solución, o mejor
dicho, saber el "¿por qué?".
Cuando un DBA empieza una frase con "GeneXus lo hace mal", denota que es un
tema personal. Como te comentaba en el mail, "*no hay diferencias
significativas*" en el UNIQUE con indice vs constraint. Si se hubiese
definido con constraint, el SQL Server igualmente termina creando un
índice, tal como indica el primer link. Si tu DBA tiene razones técnicas
que justifiquen que está mal, me gustaría escucharlas. :)
Slds
On Fri, Jan 15, 2021 at 12:36 PM Gabriel Medina |
|
|
Gabriel Medina | | |
Muchas gracias Enrique.
Justamente una de las cosas que nunca estoy seguro es de qué es lo más
conveniente.
Afortunadamente, en general no me ha tocado decidir este tipo de cosas
en *sistemas
grandes en producción, *casos en los que las decisiones las toman los *DBA* o
responsables.
Pero en me caso particular, en mis sistemas que NO son grandes, *muchas
veces prefiero* *NO tener* *Referencial *Integrity , porque las
reorgs fallan menos, y cuando fallan me causa mucha impotencia... en fin,
creo que es por desconocimiento, algunos colegas dicen que
1) *No es eficiente*
2) *La fallas de reorg *que podrían evitarse, son a causa de que la DB ya
no está bien en su integridad referencia...
3) Lo que yo digo es que a veces por una "tablita" de poca importancia
falla la Reorg, y los cambios importantes no se pueden realizar
automáticamente...
En fin, está muy mal tener configurado "Declare referencial integrity =
*NO"*
Por último el mismo amigo (DBA) me ha pasado un script para *Deshabilitar
RI*, antes de correr la *Reorg de Gx*, y luego *Habilitar RI*, es un
recurso interesante.
Si alguno quiere ese Script me lo pide.
--
Saludos,
gab
@gxsoft
On Fri, Jan 15, 2021 at 1:25 PM Enrique Almeida |
|
|
Gabriel Medina | | |
Hola Leandro,
Gracias por tu respuesta. Creo que el argumentaba, que *"era lo que debía
hacerse"* que para eso estaba. Pero además el hacer DROP de el *otro índice
natural*, de la *FK *el decía que podría afectar la performance y que se
debería haber dejado, borrarlo podía quitarle performance a la búsqueda.
Por otro lado, te copio lo que le pregunté a Enrique, por si no lo viste:
* TEMA *configurar la DB con *Referencial Integrity= : *
Justamente una de las cosas que nunca estoy seguro es de qué es lo más
conveniente.
Afortunadamente, en general no me ha tocado decidir este tipo de cosas
en *sistemas
grandes en producción, *casos en los que las decisiones las toman los *DBA* o
responsables.
Pero en me caso particular, en mis sistemas que NO son grandes, *muchas
veces prefiero* *NO tener* *Referencial *Integrity , porque las
reorgs fallan menos, y cuando fallan me causa mucha impotencia... en fin,
creo que es por desconocimiento, algunos colegas dicen que
1) *No es eficiente*
2) *La fallas de reorg *que podrían evitarse, son a causa de que la DB ya
no está bien en su integridad referencia...
3) Lo que yo digo es que a veces por una "tablita" de poca importancia
falla la Reorg, y los cambios importantes no se pueden realizar
automáticamente...
En fin, está muy mal tener configurado "Declare referencial integrity =
*NO"*
Por último el mismo amigo (DBA) me ha pasado un script para *Deshabilitar
RI*, antes de correr la *Reorg de Gx*, y luego *Habilitar RI*, es un
recurso interesante.
Si alguno quiere ese Script me lo pide.
--
Saludos,
gab
@gxsoft
On Fri, Jan 15, 2021 at 1:42 PM Leandro Minatel |
|
|
|
|
Back to gx-l |
|