Para almacenar datos de usuarios en DB: ¿Mayúsculas o minúsculas?

K3rnelpanic · 7 Octubre 2020

Hola cabr3s. Consulta para los más avezados y desarrolladores senior de este grandioso foro :zippy

¿Qué opción utilizan para almacenar los datos de los usuarios?.

Esto porque estoy "desarrollando" (lo pongo entre comillas porque es primera vez que programo algo más elaborado) y me asaltó la duda.
Yo lo haría guardando todo en mayúsculas, ya sea parseando lo ingresado por el usuario en los formularios de ingreso de datos y transformandolo a mayúsculas antes de pasarselo directo a la base de datos).
Luego, para mostrar la información transformarlo a minúsculas y de ahí a capitalizar la primera letra (por ejemplo para el almacenamiento de datos de usuario: nombre, apellido paterno, apellido materno, etc).

unreal4u · 7 Octubre 2020

Guárdalo TAL CUAL el usuario lo provee. Transformación de datos se hace en la capa de presentación.

Las razones son varias:

1) No quieres que por un bug en tu código de transformación se pierdan datos. Has considerado que llegue un Chino e ingrese
"你好，世界" como nombre o bien que un árabe escriba مرحبا بالعالم ? (Acuérdate que los árabes son RTL y no LTR)
2) En caso de problemas, siempre podrás consultar la fuente: la base de datos debe guardar datos, no hacer transformaciones.
3) Qué harás en casos como Leonardo DiCaprio? O Anneke van Giersbergen? (El adjunto va SIN mayúsculas). O bien también tienes el caso Pato López-Perez que se da en algunas situaciones.
4) Guarda el nombre completo como un solo campo: no todos tienen 2 nombres y 2 apellidos. Mi hija por ejemplo tiene 3 nombres y un apellido pero que contiene un espacio entremedio, o sea parecen dos pero en realidad es uno.

Por último, aprovecho de dejar este pequeño recordatorio con respecto al uso de nombres en bases de datos:

Falsehoods Programmers Believe About Names | Kalzumeus Software

www.kalzumeus.com

Saludos.

Zuljin · 7 Octubre 2020

No cacho. ¿No se supone que un "humano" es el que te ingresa ese tipo de datos?

Luego con funciones de la base de datos puedes hacer la magia de que te lo muestre todo en mayúsculas o la primera letra con mayúsculas y el resto con minúsculas.

Ahora que lo pienso, una buena alternativa para poder indexar mejor es sin importar como lo ingrese el usuario, tu lo puedes guardar todo en mayúsculas en el campo de la base de datos. Eso te puede servir para hacer las búsquedas internamente siempre en mayúsculas, independiente si el usuario te pone un string en minúsculas.

unreal4u · 7 Octubre 2020

Zuljin dijo:
No cacho. ¿No se supone que un "humano" es el que te ingresa ese tipo de datos?

Luego con funciones de la base de datos puedes hacer la magia de que te lo muestre todo en mayúsculas o la primera letra con mayúsculas y el resto con minúsculas.

Ahora que lo pienso, una buena alternativa para poder indexar mejor es sin importar como lo ingrese el usuario, tu lo puedes guardar todo en mayúsculas en el campo de la base de datos. Eso te puede servir para hacer las búsquedas internamente siempre en mayúsculas, independiente si el usuario te pone un string en minúsculas.

Supongo que estás hablando de Oracle, en MySQL (y también PostGreSQL) puedes buscar con COLLATION, de forma de incluir (o no) mayúsculas o minúsculas, o tratar la LL como una sola letra para calcular levenshtein, etc.

Saludos.

Zuljin · 7 Octubre 2020

unreal4u dijo:
Supongo que estás hablando de Oracle, en MySQL (y también PostGreSQL) puedes buscar con COLLATION, de forma de incluir (o no) mayúsculas o minúsculas, o tratar la LL como una sola letra para calcular levenshtein, etc.

Saludos.

En Oracle también. Lo que pasa es que hilando más fino, meter una función anula que el motor de base de datos use un índice. Para el desarrollador es transparente porque le va a traer el resultado esperado, pero el motor de base de datos probablemente no use el índice indicado sino que va a mandarle un escaneo completo a la tabla.

unreal4u · 7 Octubre 2020

Zuljin dijo:
En Oracle también. Lo que pasa es que hilando más fino, meter una función anula que el motor de base de datos use un índice. Para el desarrollador es transparente porque le va a traer el resultado esperado, pero el motor de base de datos probablemente no use el índice indicado sino que va a mandarle un escaneo completo a la tabla.

Claro, si CAMBIAS el collation es así. Si guardas los datos en el charset correcto para el usuario final será transparente. Si yo por ejemplo creo una tabla del tipo:

Código:

CREATE TABLE t1 (
  md5 CHAR(32) CHARSET ASCII COLLATE ascii_bin
);

La db sabrá que A y a son dos letras totalmente distintas. Si en cambio hago una tabla con lo siguiente:

Código:

CREATE TABLE t1 (
  bla CHAR(32) CHARSET utf8 COLLATE utf8_spanish_ci
);

La base de datos sabrá de antemano que tendrá que buscar case insensitive (*_ci) y que tendrá que aplicar las reglas españolas (a == á, la ñ está entre N y M, etc) en la búsqueda.
Ocupará los índices ya que los armó en primer lugar teniendo en consideración esas reglas. Si en cambio decides hacer un SELECT en base a COLLATION utf8_spanish2_ci ya cambia el cuento y tendrá que hacer un full-scan ya que tendrá que popular un nuevo índica on-the-fly.

Saludos.

K3rnelpanic · 7 Octubre 2020

Aerodynamic dijo:
¿Cómo te pudiste meter a la configuración de la ONT?

unreal4u dijo:
Guárdalo TAL CUAL el usuario lo provee. Transformación de datos se hace en la capa de presentación.

Las razones son varias:

1) No quieres que por un bug en tu código de transformación se pierdan datos. Has considerado que llegue un Chino e ingrese
"你好，世界" como nombre o bien que un árabe escriba مرحبا بالعالم ? (Acuérdate que los árabes son RTL y no LTR)
2) En caso de problemas, siempre podrás consultar la fuente: la base de datos debe guardar datos, no hacer transformaciones.
3) Qué harás en casos como Leonardo DiCaprio? O Anneke van Giersbergen? (El adjunto va SIN mayúsculas). O bien también tienes el caso Pato López-Perez que se da en algunas situaciones.
4) Guarda el nombre completo como un solo campo: no todos tienen 2 nombres y 2 apellidos. Mi hija por ejemplo tiene 3 nombres y un apellido pero que contiene un espacio entremedio, o sea parecen dos pero en realidad es uno.

Por último, aprovecho de dejar este pequeño recordatorio con respecto al uso de nombres en bases de datos:

Falsehoods Programmers Believe About Names | Kalzumeus Software

www.kalzumeus.com

Saludos.

Buenísima, me queda mucho más claro.

Zuljin dijo:
No cacho. ¿No se supone que un "humano" es el que te ingresa ese tipo de datos?

Luego con funciones de la base de datos puedes hacer la magia de que te lo muestre todo en mayúsculas o la primera letra con mayúsculas y el resto con minúsculas.

Ahora que lo pienso, una buena alternativa para poder indexar mejor es sin importar como lo ingrese el usuario, tu lo puedes guardar todo en mayúsculas en el campo de la base de datos. Eso te puede servir para hacer las búsquedas internamente siempre en mayúsculas, independiente si el usuario te pone un string en minúsculas.

Si, será un humano. Estoy haciendo una especie de software de cálculo de remuneraciones y derivados de rrhh, entonces será un humano el que le proveerá datos. Donde tenía la duda es en los datos del usuario (trabajador) porque he visto en distintos lugares que los datos se muestran con todo en mayúsculas, entonces me preguntaba si lo almacenaban así o se mostraba de esa forma solamente.

_V · 7 Octubre 2020

Principio KISS. No hagas transformaciones innecesarias en el almacenamiento de los datos. Uno innecesariamente trata de "ordenar" pero para estas situaciones depende de cada usuario.

K3rnelpanic · 7 Octubre 2020

Osea en resúmen dejar los datos "as is"

Para almacenar datos de usuarios en DB: ¿Mayúsculas o minúsculas?

K3rnelpanic

non serviam

unreal4u

I solve problems.

Falsehoods Programmers Believe About Names | Kalzumeus Software

Zuljin

Fundador

unreal4u

I solve problems.

Zuljin

Fundador

unreal4u

I solve problems.

K3rnelpanic

non serviam

Falsehoods Programmers Believe About Names | Kalzumeus Software

_V

The Hateful Wish

K3rnelpanic

non serviam