|

Microsoft pagará a empresas por usar su buscador

ByLuis

live2.pngMicrosoft pretende probar un programa por el cual se pagará a las empresas para que usen su buscador web Live.
A cambio de que se use su buscador, Microsoft ofrece créditos para servicios o training. Lo que pretende conseguir es que a cambio de estos créditos, los usuarios envien comentarios de valor sobre el uso del buscador web.
Incialmente ofrecerá una cantidad fija de 25.000$ a la empresa y entre 2$ y 10$ por cada computadora anualmente, dependiendo esta última cantidad de la cantidad de búsquedas que realice. Así, por ejemplo una empresa con 10.000 ordenadores y desde la que se hagan muchas búsquedas, podrá ganar unos 120.000$, y una empresa con 50.000 ordenadores y un nivel de búsquedas normal, podrá ganar unos 200.000$.
Estoy de acuerdo con opiniones sobre lo absurdo de esta medida, porque aunque yo ya he visto que los administradores te añaden en el IE una barra de búsquedas, no quita que la gente pueda usar el Firefox, o que instale la de Google, o cualquier otra cosa que evite lo que Microsoft y la empresa pretenden.
Microsoft: Use our search and we’ll pay you

Consejos para diseñar una base de datos

ByLuis

Diseñar una base de datos no es algo sencillo y sí muy importante, ya que un mal diseño conlleva dificultades para desarrollar la aplicación o una aplicación compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo.

  • Mal diseño: el diseño es lo fundamental, primero hay que saber qué es lo que se necesita mostrar para luego diseñar correctamente la base de datos. Yo personalmente me he encontrado con diseños iniciales muy básicos que luego han ido parcheando y haciendo modificaciones drásticas para ajustarlas a un modelo que era el mismo desde el inicio de la aplicación.
  • Ignorar la normalización: la normalización es fundamental para un buen rendimiento y una sencilla programación.
  • Nomenclatura no estándar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseño.
  • Falta de documentación: esto es una constante en todo el mundo de la programación, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que tú.
  • Una tabla que agrupa a muchas: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor meterlo todo en una única tabla.
  • Usar un identificador como única clave primaria: no siempre es correcto usar únicamente un identificador numérico secuencial como clave primaria única.
  • No usar las características de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaños de los campos y claves secundarias en el diseño para obtener una mejor integridad de datos.
  • No usar procedimientos almacenados para obtener los datos: es una forma de separar la capa de la base de datos de la capa del usuario. Aportan seguridad, encapsulamiento, mantenibilidad y rapidez. Yo también añadiría el uso de vistas.
  • Falta de pruebas: algo para mí muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitará la aplicación. Comprobar el tiempo de ejecución de las sentencias para añadir índices, etc…

Podéis ver todos estos puntos muy bien explicados y de forma extensa en el artículo original.

Ten Common Database Design Mistakes