miércoles, 27 de diciembre de 2017

¿Qué es Diseño UX? Los Conceptos Erróneos más Comunes y Mitos de UX


¿Qué es Diseño UX? Los Conceptos Erróneos más Comunes y Mitos de UX


Incluso después de todos estos años, parece que “UX” sigue siendo una palabra de moda en muchas compañías: “No solo necesitamos un diseñador”, declara el VP de Producto, “¡Necesitamos un Diseñador UX!”. Se escucha un grito audible en la habitación; todos en la reunión asienten mientras navegan clandestinamente “¿Qué es el diseño UX?” y “¿Qué hace un Diseñador UX ?”
Por ahora, la mayoría de la gente sabe que UXsignifica experiencia del usuario. Pero saber lo que representa no es lo mismo que comprender realmente los detalles que lo componen y hacerlo funcionar. De hecho, a la mayoría de la gente le resultaría difícil explicar qué significa el diseño para la experiencia del usuario, o lo que realmente hace el diseñador de UX.
UX — en resumen — es todos los aspectos de un sistema (sitio web, aplicación, producto, servicio, comunidad, etc.) según lo experimentado por los usuarios. Las empresas se esfuerzan por crear resultados positivos, consistentes, predecibles y deseables con UX, que pueden incluir interfaz, diseño industrial, interacciones físicas y más.
El diseño de la experiencia del usuario es la disciplina de lo que hacen los diseñadores de UX y el diseño centrado en el usuario (UCD) es el proceso de UX. Pensamiento de Diseño o Design Thinking es otro término ampliamente utilizado. Esta práctica generalmente incluye la investigación del usuario, bocetos, wireframing, diseño de interacción, diseño visual, creación de prototipos, pruebas de usuario y iteración continua en los diseños.
Design thinking, Tim Brown IDEO
Comprender el diseño de UX, lo que es y lo que no es — ayudará a todos los involucrados a crear excelentes productos con un gran UX. Con ese fin, aquí hay algunos conceptos erróneos comunes y mitos sobre el diseño de UX:

UX No Es UI

La interfaz no es la solución. El diseño de la interfaz de usuario generalmente juega un papel importante en el trabajo de un diseñador de UX, pero no es la única parte. Piénsalo de esta manera: el diseño de UX es el viaje y la UI es el destino.
El diseño de UX es un proceso de diseño estratégico de varios pasos que tiene como objetivo crear un producto o sitio que los clientes/usuarios se sienten atraídos, encuentren fácil de usar y comprendan rápidamente. Y a través del proceso de diseño de UX, llegamos a la solución de interfaz de usuario correcta.
Hay al menos diez pasos en el proceso de diseño UX de pila completa que deben tomarse antes de llegar a la interfaz de usuario final como se describe en un artículo anterior “El uso de los 10 mejores diseñadores de entrega de UX.”
  1. Análisis de objetivos comerciales y especificaciones técnicas
  2. Informes de análisis competitivos
  3. Elaboración de personajes e investigación de UX
  4. Mapa del sitio y arquitectura de la información
  5. Mapas de experiencia, viajes de usuarios y flujos de usuarios
  6. Bocetos y wireframes
  7. Maquetas y diseño de interacción
  8. Prototipos interactivos
  9. Prueba de usabilidad
  10. Diseño visual
Al final, llegando al diseño final de UI — el destino.
UX no es UI, la diferencia entre UX y UI
Illustración porShane Rounce

UX Design no es solo acerca de la estética

La estética por sí sola no brindará gran facilidad de uso; solo se refieren a cómo se ve algo. El diseño de UX se trata de cómo algo se ve, se siente y funciona.
Las grandes experiencias de usuario son imprescindibles para que el diseño de un producto digital tenga éxito. Sin duda, los grandes diseños y la estética en general son importantes, pero son simplemente el toque final que complementa un producto utilizable que también es un placer usar. Algunos lo llaman “la capa de pintura” que se aplica una vez que todo está construido. Luchar por la perfección estética mientras se abandona la usabilidad es, en última instancia, un juego perdedor.
Si UX fuera solo estética, la usabilidad del producto tendría que quedar relegada. La usabilidad es un atributo de calidad crucial que determina qué tan fácil es usar un producto. Es poco probable que un cliente se preocupe por cómo se ve un producto si no puede usarlo.
Si un producto es útil se define en términos de utilidad así como de usabilidad. La utilidad proporciona las características que las personas necesitan; la facilidad de uso es lo fácil y agradable que son esas funciones para usar. Los diseños que se centran únicamente en la estética e ignoran los principios básicos de la usabilidad terminan siendo inútiles por definición.
Cita de Jonathan Ive de Apple sobre diseño de producto

El Diseño de UX No Es Un Paso Más En El Proceso

El diseño de UX no es una casilla de verificación. Necesita integrarse en todo lo que hace una empresa.
“La mayoría de los clientes esperan que la experiencia de diseño a ser una actividad discreta, la solución de todos sus problemas con una única especificación funcional o un único estudio de investigación. Debe ser un esfuerzo continuo, un proceso de aprendizaje continuo acerca de los usuarios, respondiendo a sus comportamientos, y evolucionando el producto o servicio.”
En lugar de ser solo un paso en el proceso de diseño, el diseño de UX es un compromiso iterativo y continuo de pensamiento de diseñoalrededor de un cliente. interacciones con los servicios y productos de una compañía. Nunca termina.
Por ejemplo, la Interaction Design Foundationdefine el diseño de UX como: “El proceso de creación de productos que brindan experiencias significativas y personalmente relevantes. Esto implica el diseño cuidadoso tanto de la usabilidad del producto y el placer que los consumidores obtendrán al usarlo. También le preocupa todo el proceso de adquisición e integración del producto, incluidos los aspectos de desarrollo de marca, diseño, usabilidad y funcionalidad “.
Cita de Ralph Caplan: Pensando en el diseño

El Diseño UX No Se Trata Sólo Del Diseño De Un Producto Digital

El diseño de UX no termina en los bordes de la pantalla de un usuario. Tampoco es una capa o componente de un producto o servicio; es toda la experiencia trabajando en todos los niveles contextualmente como un todo interconectado.
El diseño de UX considera los momentos humanos en contexto e incorpora todos los aspectos del ecosistema en el que se emplea un producto. Se trata de diseñar una experiencia holística cuando “el todo se considera más que la suma de sus partes” y mantener este sesgo a lo largo del ciclo de vida del consumidor, junto con todos los puntos de contacto donde un usuario interactúa con un producto.
Como dice Don Norman: “La experiencia del usuario abarca todos los aspectos de la interacción del usuario final con la empresa, sus servicios y sus productos”.
“El diseño UX no se limita a los confines de la computadora. Ni siquiera necesita una pantalla… La experiencia del usuario es cualquier interacción con cualquier producto, cualquier artefacto, cualquier sistema”.
  • Bill DeRouchey, Director de diseño de interacción en Ziba Design.
img alt tag: Cita de Steve Jobs sobre la importancia del diseño UX

El Diseño UX No Se Trata Sólo De Usabilidad

Sin lugar a dudas, la facilidad de uso es de suma importancia para que la experiencia del usuario sea un éxito. Sin embargo, muchas cosas conforman lo que está bajo el paraguas de la experiencia del usuario, y la usabilidad es solo un aspecto del mismo. Una interfaz de usuario puede diseñarse para ser extremadamente útil, pero se queda corto cuando se trata de entregar las cosas correctas, en el momento correcto y de la manera correcta.
Como se mencionó anteriormente, una UI puede ser estéticamente agradable y un placer de usar, pero falla miserablemente cuando se analiza bajo el microscopio de análisis heurístico donde se verifican todas las cajas que conforman una buena usabilidad.
Evaluación heurística de la usabilidad del diseño de UI y UX
Una evaluación heurística revela mala usabilidad. Un ejemplo de un evaluador heurístico que identifica problemas de usabilidad (panel de control por Corey Haggard).
Un gran producto debería satisfacer a los usuarios en muchos niveles. Debería ser:
Útil ¿Hay alguna razón por la que debería usar esto? ¿Sirve un propósito? Satisface las necesidades?
Usable ¿Es intuitivo? ¿Es fácil de usar? ¿Es accesible?
Deseable ¿Es estéticamente agradable? ¿Está diferenciado? ¿Es memorable?
Sostenible ¿Se puede mantener? ¿Puede evolucionar? ¿Puede ser soportado? ¿Se puede escalar?
Social ¿Facilita la conversación? ¿Es compatible con compartir? ¿Alienta a la comunidad?
“Inutilizable” significa “me estoy moviendo”, y no importa cuán atractivo sea el diseño visual — qué tan elegante es la micro-animación — si estropeas el diseño de UX y tu experiencia de usuario morirá. Hazlo bien y estarás en camino hacia un UX mucho mejor. El producto tendrá una mayor posibilidad de éxito, lo que a su vez contribuirá al resultado final.
“Si bien la usabilidad es importante, su enfoque en la eficiencia y la efectividad parece difuminar los otros factores importantes en UX, que incluyen la capacidad de aprendizaje y las respuestas emocionales viscerales y conductuales a los productos y servicios que utilizamos”.
– David Malouf, Professor of interaction design Savannah College of Art & Design
Cita por Jacob Nielsen

El Diseño UX No Es Sólo Sobre El Usuario

El diseño UX también debe cumplir con los objetivos y las metas del negocio. Todo comienza con una comprensión de la visión del producto, es decir, la razón de la existencia del producto desde una perspectiva comercial. El mercado objetivo debe ser considerado, el problema debe ser abordado y una solución viable diseñada.
Si un diseñador UX solo se enfoca en crear experiencias óptimas para los usuarios mientras se descuidan los objetivos de negocio, fallarán. Muchos especialistas UX novatos cometen este error y proponen recomendaciones que no son realistas. Las empresas deben ser rentables para existir.
Usando el Framework S.M.A.R.T. al definir los objetivos de negocio para un proyecto UX es una forma de ver las necesidades del negocio. INTELIGENTE. significa: específico, medible, procesable, realista y basado en el tiempo. Los diseñadores necesitan ver su trabajo desde una perspectiva comercial, pensar estratégicamente, considerar los objetivos principales y el diseño para los usuarios y los objetivos comerciales.
“Simplemente no siempre podemos hacer lo mejor para los usuarios. Hay un conjunto de objetivos comerciales que deben cumplirse, y también estamos diseñando para eso.”
  • Russ Unger, Director de planificación de la experiencia, DraftFCB
Cita de Diseño UX de Susan Weinschenk
Like what you're reading?
Get the latest updates first.
No spam. Just great design posts.

El Diseño UX No Es Caro

Es cierto que uno podría gastar mucho, “ir a todo o nada”, utilizando todo el espectro de métodos y herramientas que componen todo el proceso de UX. En realidad, nadie realmente hace esto. La mayoría de las empresas usan la excusa de los altos gastos (un mito) y no tienen tiempo suficiente para renunciar a la implementación de las actividades de diseño de UX más vitales, como la investigación del usuario y las pruebas de los usuarios. De hecho, especialmente cuando se trata de investigación de usuarios, las empresas no pueden permitirse no hacerlo.
En realidad, los mejores diseñadores de UX tienen una caja de herramientas de opciones, seleccionando y eligiendo métodos que tengan sentido para el proyecto y presupuesto en particular. Por ejemplo, sin gastar mucho, se pueden descubrir grandes oportunidades de diseño y obtener mucha información de la investigación de usuarios con tan solo cinco usuarios. Del mismo modo, armar un prototipo de producto simple y probarlo con cinco usuarios es barato, revelará la mayoría de los problemas de usabilidad y mostrará al equipo del producto lo que funciona y lo que no.
Otro método es análisis heurístico. Con tan solo cinco evaluadores expertos, es una forma rentable de detectar más del 80% de los problemas de usabilidad con el diseño de un producto — y no es costoso, especialmente cuando uno considera el costo de no hacer pruebas de usabilidad .
“El mal diseño crea fricción”.
El mal UX es más costoso que el bueno. Las consecuencias de un UX pobre siempre se suman a una gran fricción para el usuario. La fricción conduce a la frustración y cuando se produce una frustración extrema, las personas simplemente abandonan el producto.

El Retorno de la Inversión del Diseño de UX


El Diseño UX No es Sólo El Papel de Una Persona o Departamento

Centrarse en la experiencia del cliente debe ser responsabilidad de toda la empresa. Cuando las empresas no adoptan una metodología de diseño centrada en el cliente en torno a sus productos y servicios, están seguros de que ser superado por un competidor que lo haga. Relegar a los profesionales del diseño de UX para que trabajen de forma aislada y las “cosas bonitas” después de que un producto ya está construido es un gran error.
Integrar el diseño centrado en el usuario (UCD) en la visión, misión y cultura de una empresa es vital. Todas las compañías más exitosas lo hacen. El diseño de UX tiene una variedad de definiciones diferentes; algunos lo llaman “diseño centrado en el cliente”, como lo hace Amazon, o experiencia del cliente (CX), o “diseño del servicio”.
El UX es responsabilidad de toda la empresa

El Diseño UX No Es Una Sola Disciplina

Un diseñador de UX es un practicante de pensamiento de diseño, un “jinete de todas las disciplinas UX” cuyo enfoque es la satisfacción del cliente con un producto . Muchas disciplinas diferentes conforman diseño de UX, que es un término general para un vasto universo de disciplinas, enfoques, metodologías y herramientas. Algunos de estos son: análisis de objetivos comerciales, análisis competitivo, desarrollo personal, investigación del usuario, mapeo de empatía, viajes de usuario, arquitectura de la información, estrategia de contenido, diseño de interacción, diseño de interfaz, diseño visual, prototipadoanálisis heurístico, y pruebas de usuario … por mencionar solo algunas.
El modelo de experiencia del usuario
El modelo de experiencia del usuario (por Corey Stern, cubiux.com)

UX Design is Not Optional

En el diseño UX del mundo de hoy no puede ser una idea de último momento. Es equivocado pensar que es un “complemento” y algo que las empresas hacen después de que se hace “cosas importantes”, como definir objetivos comerciales, estudios de mercado, documentos de requisitos del producto (PRD), ingeniería, ventas y marketing. En estos días, integrar el diseño de UX en todo lo que hace una empresa es crucial.
Los productos no son sobre características y funcionalidad. Los sitios web, aplicaciones o productos B2B SaaS no son solo utilidades. Las empresas no obtienen el máximo rendimiento de su inversión si el resultado es solo una respuesta emocional momentánea de los clientes, ya que los esfuerzos de diseño se basaron solo en la utilidad y la estética. Cualquier respuesta emocional positiva a largo plazo tiene que tener un fuerte componente de valor y debe estar intrincadamente diseñada en el producto para complacer y deleitar a los usuarios de manera constante. Entonces, el diseño de UX no es simplemente una opción. Es una necesidad absoluta para que las empresas tengan éxito a largo plazo.
Cita de Tim Cook sobre excelentes productos y cómo debería funcionar el diseño de UX

Resumen

El diseño UX se trata esencialmente de mejorar la satisfacción del cliente y la lealtad al brindar una experiencia positiva en todos los puntos de contacto que experimenta un cliente cuando interactúa con una marca o empresa.
Un estudio reciente de Forrester Research muestra que una interfaz bien diseñada podría elevar la tasa de conversión de un sitio web hasta en un 200%, y un mejor diseño de UX podría generar tasas de conversión de hasta 400%. No hay discusión con los números — las métricas hablan por sí mismas.
Una vez que se eliminan los mitos y se corrigen las creencias erróneas sobre el diseño UX, se hace evidente que el efecto del diseño UX es extenso (como lo son sus beneficios) y que un proceso de UX debe integrarse en todo una compañía lo hace

El articulo original lo puede encontrar en el siguiente enlace.

jueves, 14 de diciembre de 2017

Malas Prácticas en el Diseño de la Base de Datos: ¿Estás Cometiendo estos Errores?


Malas Prácticas en el Diseño de la Base de Datos: ¿Estás Cometiendo estos Errores?



Cada vez que como desarrollador, se te asigna una tarea basada en el código existente, debes enfrentar muchos desafíos. Uno de esos desafíos—la mayoría de las veces el más exigente, implica la comprensión del modelo de datos de una aplicación.
Normalmente te enfrentas a tablas, vistas, columnas, valores, procedimientos almacenados, funciones, restricciones y desencadenantes confusos que tardan mucho tiempo en tener sentido para ti. Y una vez que lo tienen, comienzas a notar muchas maneras de mejorar y aprovechar la información almacenada.
Si eres un desarrollador experimentado, es probable que también notes cosas que podrían haberse hecho mejor al principio, es decir, defectos de diseño.
Malas Prácticas de Diseño de Bases de Datos
En este artículo aprenderás sobre algunas de las malas prácticas de diseño de bases de datos comunes, por qué son malas y cómo puedes evitarlas.

Mala Práctica N° 1: Ignorar el Propósito de la Data

Los datos se almacenan para ser consumidos más tarde y el objetivo siempre es almacenarlos y recuperarlos de la manera más eficiente. Para lograr esto, el diseñador de la base de datos debe saber de antemano qué representarán los datos, cómo se va a adquirir y a qué velocidad, cuál será su volumen operativo (es decir, cuántos datos se esperan) y, finalmente, cómo se usará.
Por ejemplo, un sistema de información industrial donde los datos se recopilan manualmente todos los días no tendrá el mismo modelo de datos que un sistema industrial, donde la información se genera en tiempo real. ¿Por qué? Porque es muy diferente manejar cientos o miles de registros por mes en comparación con gestionar millones de ellos en el mismo período. Los diseñadores deben tener consideraciones especiales para mantener la eficiencia y la usabilidad de la base de datos si los volúmenes de datos van a ser grandes.
Pero, por supuesto, el volumen de datos no es el único aspecto a considerar ya que el propósito de los datos también afecta el nivel de normalización, la estructura de datos, el tamaño del registro y la implementación general de todo el sistema.
Por lo tanto, conocer a fondo el propósito del sistema de datos que creará conduce a consideraciones sobre la elección del motor de la base de datos, las entidades a diseñar, el tamaño y formato del registro y las políticas de administración del motor de la base de datos.
Ignorar estos objetivos conducirá a diseños defectuosos en sus aspectos básicos, aunque sean correctos estructural y matemáticamente.

Mala Práctica N° 2: Mala Normalización

Diseñar una base de datos no es una tarea determinista; dos diseñadores de bases de datos pueden seguir todas las reglas y principios de normalización para un problema determinado y, en la mayoría de los casos generarán diferentes diseños de datos. Esto es inherente a la naturaleza creativa de la ingeniería de software. Sin embargo, hay algunas técnicas de análisis que tienen sentido en cada instancia y seguirlas es la mejor manera de acceder a una base de datos que rinde al máximo.
Imagen de un conjunto de datos que conduce a dos diseños diferentes
A pesar de esto, a menudo nos enfrentamos con bases de datos que fueron diseñadas sobre la marcha, sin seguir las reglas más básicas de normalización. Tenemos que tenerlo claro: cada base de datos debe, al menos, normalizarse a la tercera forma normal ya que es el diseño que mejor representará a sus entidades y cuyo rendimiento se equilibrará mejor entre consultas e inserción-actualización-eliminación de registros.
Si te encuentras con tablas que no cumplen con3NF, 2NF, o hasta 1NF, considera rediseñar estas tablas. El esfuerzo que inviertas para hacerlo valdrá la pena en muy corto plazo.

Mala Práctica N° 3: Redundancia

Muy relacionado con el punto anterior ya que uno de los objetivos de normalización es reducirlo, la redundancia es otra mala práctica que aparece muy a menudo.
Los campos y tablas redundantes son una pesadilla para los desarrolladores ya que requieren lógica de negocios para mantener actualizada gran parte de la misma información. Esto es una sobrecarga que puede evitarse si las reglas de normalización se siguen al pie de la letra. Aunque a veces puede parecer necesaria la redundancia, debe utilizarse sólo en casos muy específicos y debe estar claramente documentada para poder tenerse en cuenta en futuros desarrollos.
Los efectos negativos típicos de la redundancia son un aumento innecesario del tamaño de la base de datos, los datos son propensos a la inconsistencia y disminuye la eficiencia de la base de datos pero—más importante—podría llevar a una corrupción en la data.

Mala Práctica No. 4: Integridad Referencial Mala (Restricciones)

La integridad referencial es una de las herramientas más valiosas que proporcionan los motores de base de datos para mantener la calidad de los datos en su mejor forma. Si no se implementan restricciones o muy pocas restricciones desde la etapa de diseño, la integridad de los datos tendrá que depender totalmente de la lógica de negocios, lo que la hace susceptible a errores humanos.

Mala Práctica N° 5: No Aprovechar las Características del Motor de Base de Datos

Cuando estás usando un motor de base de datos, tienes una poderosa pieza de software para tus tareas de manejo de datos que simplificará el desarrollo del software y garantizará que la información sea siempre correcta, segura y utilizable. Un Motor de Base de Datos proporciona servicios como:
  • Vistas que proporcionan una manera rápida y eficiente de ver tus datos, por lo general desincronizándolos para fines de consulta sin perder la corrección de los datos.
  • Índices que ayudan a acelerar las consultas en las tablas.
  • Funciones agregadas que ayudan a analizar información sin programación.
  • Transacciones o bloques de oraciones que alteran los datos que se ejecutan y comprometen o cancelan (retrotraen) si ocurre algo inesperado, manteniendo así la información en un estado permanentemente correcto.
  • Bloqueos que mantienen los datos seguros y correctos mientras se ejecutan las transacciones.
  • Procedimientos almacenados que proporcionan funciones de programación para permitir tareas complejas de administración de datos.
  • Funciones que permiten cálculos sofisticados y transformaciones de datos.
  • Restricciones que ayudan a garantizar la exactitud de los datos y evitar errores.
  • Disparadores que ayudan a automatizar las acciones cuando ocurren eventos en los datos.
  • Comando optimizador (planificador de ejecución) que se ejecuta bajo el capó, asegurando que cada frase se ejecuta en su mejor momento y manteniendo los planes de ejecución para futuras ocasiones. Ésta es una de las mejores razones para usar vistas, procedimientos almacenados y funciones ya que sus planes de ejecución se mantienen permanentemente en el Motor de Base de Datos.
No conocer o ignorar estas capacidades llevará el desarrollo a un camino extremadamente incierto y seguramente a errores y problemas futuros.
Like what you're reading?
Get the latest updates first.
No spam. Just great engineering posts.

Mala Práctica N° 6: Claves Primarias Compuestas

Este es un punto de controversia ya que muchos diseñadores de bases de datos hablan hoy sobre el uso de un campo generado automáticamente como ID principal como la clave principal en lugar de un compuesto definido por la combinación de dos o más campos. Esto se define actualmente como la “mejor práctica” y, personalmente, tiendo a estar de acuerdo con ella.
Imagen de una Clave Primaria Compuesta
Sin embargo, esto es solo una convención y por supuesto, el Motor de Base de Datos permite la definición de claves primarias compuestas, que muchos diseñadores piensan que son inevitables. Por lo tanto, al igual que con la redundancia, las claves primarias compuestas son una decisión de diseño.
Sin embargo, ten en cuenta que si esperas que tu tabla con una clave primaria compuesta tenga millones de filas, el índice que controla la clave compuesta puede crecer hasta un punto en el que el rendimiento de la operación CRUDestá muy degradado. En ese caso, es mucho mejor usar una clave primaria ID simple que tenga un índice lo suficientemente compacto y establezca las restricciones de Motor de Bases de Datos necesarias para mantener la singularidad.

Mala Práctica N° 7: Mala Indexación

A veces tendrás una tabla que necesitas consultar por muchas columnas. A medida que la mesa crezca, notarás que los SELECT en estas columnas se ralentizan. Si la tabla es lo suficientemente grande, pensarás lógicamente, en crear un índice en cada columna que uses para acceder a esta tabla pero notarás casi de inmediato que el rendimiento de los SELECT mejora, pero INSERT, UPDATE y DELETE caen. Esto por supuesto se debe al hecho de que los índices deben mantenerse sincronizados con la tabla, lo que significa una sobrecarga masiva para el Motor de Base de Datos. Este es un caso típico de indexación excesiva que puedes resolver de muchas maneras; por ejemplo, tener solo un índice en todas las columnas diferentes a la clave principal que utilizas para consultar la tabla, ordenar estas columnas de las más utilizadas a las menos puede ofrecer un mejor rendimiento en todas las operaciones de CRUDque un índice por columna.
Por otro lado, tener una tabla sin índice en las columnas que se utilizan para consultarlo conducirá, como todos sabemos, a un bajo rendimiento en SELECTs.
Además, la eficiencia del índice depende a veces del tipo de columna; los índices en columnas INT muestran el mejor rendimiento posible pero los índices en VARCHAR, DATE o DECIMAL (si llega a tener sentido) no son tan eficientes. Esta consideración puede incluso llevar a rediseñar tablas a las que se debe acceder con la mejor eficiencia posible.
Por lo tanto, la indexación es siempre una decisión delicada ya que demasiada indexación puede ser tan mala como muy poca y porque el tipo de datos de las columnas a indexar tiene una gran influencia en el resultado final.

Mala Práctica N° 8: Convenciones de Nomenclatura Deficiente

Esto es algo con lo que los programadores siempre luchan cuando se enfrentan a una base de datos existente: entendiendo qué información está almacenada en ella por los nombres de tablas y columnas porque a menudo no hay otra manera.
El nombre de la tabla debe describir qué entidad contiene y cada nombre de columna debe describir qué parte de la información representa. Esto es fácil, pero comienza a ser complicado cuando las tablas tienen que relacionarse entre sí. Los nombres comienzan a ensuciarse y, lo que es peor, si hay convenciones de nombres confusas con normas ilógicas (como, por ejemplo, “el nombre de la columna debe tener 8 caracteres o menos”). La consecuencia final es que la base de datos se vuelve ilegible.
Por lo tanto, una convención de nomenclaturasiempre es necesaria si se espera que la base de datos perdure y evolucione con la aplicación que apoya y aquí hay algunas pautas para establecer una versión concisa, simple y legible:
  • Sin limitaciones en el tamaño del nombre de tabla o columna. Es mejor tener un nombre descriptivo que un acrónimo que nadie recuerde o entienda.
  • Los nombres que son iguales tienen el mismo significado. Evita tener campos que tengan el mismo nombre pero con diferentes tipos o significados; esto será confuso tarde o temprano.
  • A menos que sea necesario, no seas redundante. Por ejemplo, en la tabla “Artículo”, no es necesario tener columnas como “Nombre del elemento”, “Precio del artículo” o nombres similares; “Nombre” y “Precio” son suficientes.
  • Ten cuidado con las palabras reservadas para el Motor de Base de Datos. Si una columna debe llamarse “Índice”, que es una palabra reservada de SQL, intenta utilizar una diferente como “NúmeroÍndice.”
  • Si se apega a la regla de la clave primaria simple (autogenerado único entero), asígnale el nombre “Id” en cada tabla.
  • Si se une a otra tabla, define la clave foránea necesaria como un entero, llamado “Id” seguido del nombre de la tabla unida (ej., IdItem).
  • Si se nombran restricciones, usa un prefijo que describa la restricción (por ejemplo, “PK” o “FK”), seguido del nombre de la tabla o tablas involucradas. Por supuesto, el uso de guiones bajos (“_”) con moderación ayuda a que las cosas sean más legibles.
  • Para nombrar índices, usa el prefijo “IDX” seguido del nombre de la tabla y la columna o columnas del índice. Además, usa “ÚNICO” como prefijo o sufijo si el índice es único y subraya cuando sea necesario.
Hay muchas pautas de nombres de bases de datos en Internet que arrojarán más luz sobre este aspecto tan importante del diseño de la base de datos pero con estos pasos básicos, al menos puedes acceder a una base de datos legible. ¡Lo importante aquí no es el tamaño o la complejidad de las pautas de nomenclatura sino su coherencia al seguirlas!

Algunas Observaciones Finales

El diseño de la base de datos es una combinación de conocimiento y experiencia; la industria del software ha evolucionado mucho desde sus inicios. Afortunadamente, hay suficiente conocimiento disponible para ayudara los diseñadores de bases de datos a lograr los mejores resultados.
Hay buenas directrices en el diseño de base de datos en todo el internet, así como malas prácticas y cosas que evitar en el diseño de la base de datos. Solo elije y mantenlo.
Y no lo olvides, es sólo a través de la experimentación, los errores y los éxitos que se aprende así que adelante y comienza ahora.
El articulo original lo puede encontrar en el siguiente enlace.