¿Cuál es el mejor diseño de base de datos para miles de filas

Question

Estoy a punto de iniciar un Database Design que simplemente administrará los usuarios en las empresas.

• Cada empresa tendrá un área de administración que se pueden administrar a los usuarios
• Cada empresa tendrá alrededor de 25.000 usuarios
• cliente cree que tiene alrededor de 50 empresas para comenzar a

Mi pregunta principal es

¿Debo crear tablas basadas en las empresas? como

users_company_0001users_company_0002users_company_0003 ...

ya que cada empresa nunca va a usar "otros" usuarios y nada tendrán que resumir/cuenta diferentes mesas en toda user_company (un simple JOIN hará el truco, aunque es más caro (tiempo) que funcionará como tener la imagen principal, esto nunca va a ser necesario.

o debo crear una mesa users que tiene (50 x 25000) usuarios (y creciente)

Estoy pensando en la primera opción, sin embargo, no estoy seguro de cómo usaría Entity Framework en dicho diseño ... Probablemente necesitaría volver a los 90 y generar mi Data Logic Layer a mano .

tiene que será una simple llamada a procedimientos memoria que contiene la identificación de la compañía

¿Qué va a sugerir?

La aplicación del sistema será ASP.NET (probablemente MVC, todavía estoy tratando de resolver esto como todos mis conocimientos está en formularios web, aunque vi vídeos de Scott Hanselman MVC - costuras fácil - pero Sé que no será tan fácil ya que los problemas vendrán y tomaré más tiempo para solucionarlos), más Microsoft SQL.

Answer 1

Aunque haya descrito esto como una relación 1-many, Todavía diseñaría la base de datos como muchos para proteger contra un cambio futuro en los requisitos.Algo así como:

Answer 2

re: ¿Debo crear tablas basadas en las empresas? sí

como

users_company_0001 users_company_0002 users_company_0003 

no, como

companyID companyName, contactID 

o debo crear una tabla de usuarios para tener (50 x 25000) 1 250 000 usuarios (y creciente) sí

Answer 3

Creo que se debe crear tablas separadas para la empresa y el usuario. A continuación, una tercera tabla para conectar los dos: CompanyAdmin. Algo así como:

• Compañía (Company_id, COMPANY_NAME, ...)
• usuario (User_Id, Nombre_de_usuario, ...)
• CompanyAdmin (Company_id , uSER_ID)

De esta forma puede agregar usuarios y/o compañías sin afectar el número de las tablas que necesita administrar. En general, es un mal diseño en el que usted necesita para modificar la base de datos (es decir. Añadir tablas) cuando se añaden nuevos datos (empresas) en el sistema.

Con la indexación adecuada, los costos de unión en una base de datos que contiene algunos millones de filas no deberían ser un problema.

Finalmente, si alguna vez necesita cambiar o registrar información adicional acerca de Compañías, Usuarios o la relación entre ellos, esta configuración debe tener el menor impacto posible en su aplicación .

Answer 4

Al haber trabajado con una base de datos SQL Server de varios terabytes y tener experiencia con cientos de tablas en el transcurso de mi carrera con filas multimillonarias, puedo decir con total seguridad que SQL Server puede manejar un company y users tablas sin particionar. Siempre está ahí cuando lo necesite, pero su preocupación no debe ser sobre sus tablas: elija el esquema más simple que satisfaga sus necesidades. Si desea hacer algo para optimizar el rendimiento, seguramente su cuello de botella será sus discos. No compre discos grandes y lentos. Consígase a sí mismo un montón de pequeños discos de RPM altos y distribuya sus datos a través de ellos tanto como sea posible, y no comparta los discos con sus registros y sus datos. Con las bases de datos, casi siempre es mejor lograr el rendimiento con un buen hardware, un buen subsistema de disco y una indexación adecuada. No comprometa ni complique demasiado su esquema tratando de anticipar el rendimiento; lo lamentará. He visto bases de datos realmente grandes donde ese tipo de cosas era necesario, pero el tuyo no lo es.