Saltar al contenido principal

 none
Instancia SQL Server o base de datos RRS feed

  • Pregunta

  • Hola

    Estoy ponindo un servidor casero, en el cual voy a guardar datos en la base de datos de XML...

    Este servidor le va a dar datos a aproximadamente 1000 usuarios

    Mi duda es la siguiente:

    Es mejor utilizar base de datos para CADA USUARIO - CLIENTE ó CREAR UN NUEVA INSTANCIA DE SQL SERVER PARA CADA USUARIO - CLIENTE ?

     Si sus respuesta es crear bases de datos, habira que ir creando 1 base de datos por ususario - cliente, o sea llegarian a ser 1000 base de datos..

    Si sus respuesta es crear una nueva instancia, habria que ir creando 1 nueva instancia por ususario - cliente, o sea llegarian a ser 1000 instancias de SQL SERVER..

    Que me aconsejan...

    Gracias de antemano.


    domingo, 10 de noviembre de 2019 15:52

Todas las respuestas

  • Hola rodolopa:

    Es mejor utilizar base de datos para CADA USUARIO - CLIENTE ó CREAR UN NUEVA INSTANCIA DE SQL SERVER PARA CADA USUARIO - CLIENTE ?

    ¿Que es para ti una nueva instancia?,  te refieres al código de un lenguaje de alto nivel. SqlConnection, SqlCommand?

    domingo, 10 de noviembre de 2019 22:47
  • Ojo, las instancias tienen un límite, que si no me equivoco es de 256. Así que no puedes crear una instancia para cada uno de los 1000 clientes. Y aunque pudieses, no te conviene porque cada instancia reserva su propio bloque de memoria, con lo que requerirías un servidor "enorme" que estaría desaprovechado la mayor parte del tiempo.

    Crear 1000 bases de datos en una sola instancia sí que es posible, aunque es bastante más que el número que se suele usar en un servidor típico.

    Hay otras opciones que a lo mejor te convienen, dependiendo de qué manejo de datos tengas que hacer para los clientes: Una es usar un esquema distinto para cada cliente, dentro de la misma base de datos (es decir, llamar a las tablas como nombrecliente.nombretabla). Se pueden asignar permisos distintos a cada esquema, de forma que puedes garantizar que cada cliente no tiene permiso de acceso las tablas de los otros clientes.

    Otra es usar un único conjunto de tablas y distinguir los registros usando un campo de "código de cliente". En este caso, es responsabilidad de tu programa el garantizar que no le devuelve datos de un cliente a otro cliente.

    lunes, 11 de noviembre de 2019 7:46
  • Gracias Miguel por contastar..

    A ver si entendi...

    En vez de una base de datos por cliente, tu dices crear una tabla por cliente, ejemplo: Facturas_Cliiente_1, facturas_Cliente_2, etc, y el otro es separar los datos de los cleintes por su nombre en una misma base de datos...

    Entendi bien ?

    Si es asi...la base de datos no se haria muy grande teniedo datos de 1000 clientes ?

    Lo que voy a almacenar son adtos de sus facturas digitales unicamente...

    Te agradezco y espero tu respuesta...

    Buen dia   

    lunes, 11 de noviembre de 2019 22:39
  • Hola Pablo..

    Una nueva instancia es una nueva instalacionde del SQL Server, por decirlo asi...

    Alguna idea ?

    Gracias

    lunes, 11 de noviembre de 2019 22:40
  • Hola rodolopa:

    Las facturas de 1000 clientes no son ningún hándicap para sql server. ¿De cuantos decenas, cientos o miles de millones de registros hablamos, para que te de miedo una sola base de datos?

    Una tabla con mil clientes. 

    Y varias tablas con todas las facturas digitales de mil clientes, con su cabecera relacionada con el cliente, detalle etc...

    Si te parece un problema que la base de datos alcance un tamaño muy grande, siempre puedes particionar las tablas.

    https://www.sqlshack.com/es/particionamiento-de-tablas-de-bases-de-datos-en-sql-server/

    martes, 12 de noviembre de 2019 5:18
  • A ver si entendi... [...], ejemplo: Facturas_Cliiente_1, facturas_Cliente_2, etc,

    No, no lo entendiste. Si lo haces así no tiene ninguna ventaja en comparación con crear una sola tabla y meter dentro todos los datos separándolos por código de cliente (cosa que también es válida, no te preocupes por el número de registros -- puedes meter cientos de millones en una tabla y funciona bien a condición de que esté bien indexada).

    Lo que yo decía era crear un esquema por cliente ("CREATE SCHEMA Cliente1") y luego llamar a la tabla Cliente1.Facturas (observa el "nombre de dos partes" separado por un punto). Esto tiene la ventaja de que puedes conceder permisos sobre el esquema "Cliente1" a la cuenta que use para hacer login el Cliente1, por lo que te aporta un nivel de seguridad dado que gracias a este mecanismo garantizas que un cliente no puede acceder a los datos de otro cliente. También puedes asignar ese esquema como predeterminado para el Login, de manera que luego en las consultas simplemente accedes a la tabla "Facturas" y el sistema ya sabe usar la tabla adecuada para cada cliente. Por supuesto, si no estás usando logins distintos para cada cliente entonces esto no te aporta ninguna ventaja, en ese caso sería preferible usar la tabla única con código de cliente o usar bases de datos distintas.

    martes, 12 de noviembre de 2019 7:03
  • Entonces podria sera asi

    Base de datos --- Datos

    Creo dentro de la base de datos un SCHEMA,

    Por decir Facturas

    Y adentro de Facturas Cliente1, Cliente2, Etc...

    Entendi bien ?

    Gracias por su amable respuesta

    miércoles, 13 de noviembre de 2019 16:43
  • No, no entendiste bien. Tiene que ser al revés de como lo has puesto.

    Creas un schema Cliente1, otro schema Clente2, etc.

    Y luego las tablas son Cliente1.Facturas, Cliente2.Facturas, etc.

    De lo contrario no sirve para nada el esquema. Si quieres que sirva para asignar permisos y para asignárselo de forma predeterminada al login, tiene que ser en este orden y no al revés.

    miércoles, 13 de noviembre de 2019 19:00
  • A ver si le entendio

    Entonces seria la base de datos -- DATOS

    Despues creo los SCHEMAS 

      Cliente1, Cliente2, etc

    Y ahora las tablas

     Cliente1.Facturas, Cliente2.Facturas, etc.

    Estoy bien asi...?

    Gracias por tu respuesta...

    jueves, 14 de noviembre de 2019 1:14
  • Sí, así está bien.

    Pero antes de lanzarte a hacerlo, revisa el razonamiento sobre por qué te aconsejaba hacerlo de esta manera, y fíjate en que solo tiene interés en caso de que estés usando un Login distinto para cada cliente. Si no estás usando logins distintos, se pierden las ventajas que tiene el crear las tablas de esta manera.

    jueves, 14 de noviembre de 2019 7:23
  • Cual es la ventaja de usar login distinoto ?

    Por que pierde efectividd al no usar login distinto...?

    La idea es hacer un facturador para alrededor de 1000 clientes distintos,,,

    Tu me aonsejas ponerle login difernete a daca cliente ?

    Gracias, muy amable..

    jueves, 14 de noviembre de 2019 16:17
  • A ver, vuelve para atrás, que esto ya lo hemos explicado antes.

    Un problema serio cuando se hace una aplicación que maneja información de distintos clientes es que hay que ser cuidadosísimo para que unos clientes no puedan acceder a la información de otros, por razones de privacidad y confidencialidad.

    Como primer paso, esto requiere autenticación, es decir, cada cliente tiene que hacer login al acceder a la aplicación para que podamos diferenciarlo de ortos clientes. Este "login" no tiene por qué propagarse a la base de datos, podría ser solo un login para la aplicación. Pero si lo propagamos a la base de datos (cosa que no es trivial, requiere esfuerzo adicional de programación) entonces ganamos un nivel más de protección, porque no solo nos protege el programa sino además también la base de datos.

    Suponiendo que efectivamente tomemos esa decisión (que, como digo, supone esfuerzo adicional, no funciona automáticamente por sí sola) entonces hay que decidir cómo queremos que la base de datos aplique esa protección adicional debida al login que le aportamos.

    Una opción es hacerlo por base de datos, que era una de las opciones que tú sugerías al principio. En este caso, cada login tendría acceso únicamente a una base de datos distinta. Pero requiere crear 1000 bases de datos si tienes 1000 clientes.

    Otra opción es crear 1000 esquemas en una base de datos (lo cual es más "liviano" para el servidor que crear 1000 bases de datos). En este caso, cada login recibe permisos sobre un único esquema. Y además nos conviene asignar ese esquema como default para el login, con el fin de evitar que se nos compliquen las queries SQL. Al asignarlo como predeterminado, no necesitamos escribir el nombre del esquema en todas y cada una de las consultas.

    Insisto en que esto es costoso de hacer y hay que tener conocimientos de lo que se está haciendo. No "aparece solo" en tu base de datos y en tu programa solo porque decidas usarlo. Pero si decides NO usarlo, entonces hay que ser super-cuidadoso en la programación para tener la absoluta certeza de que no existe en nuestro programa ningún error que pueda hacer que un cliente vea (o peor: modifique) las facturas de otro cliente.

    jueves, 14 de noviembre de 2019 17:11
  • ëro la idea mia original era mas que todo, separar los datos por cleinte...sin importar el login..El login puede ser el mismo para todos...

    Estaria bien asi...?

    Usted me dice que perderia efectividad...

    Algun ejemplo de ponerle un login a cada esquema en el ejemplo que le puse arriba ¡ 

    Base de datos -- DATOS

    SCHEMAS 

    Cliente1, Cliente2, etc

    Tablas

     Cliente1.Facturas, Cliente2.Facturas, etc.

    Cmo seria en codigo TRANSAC poner un login a cada una ?

    Gracias por tu respuesta...

    jueves, 14 de noviembre de 2019 22:02
  • > El login puede ser el mismo para todos. Estaria bien asi...?

    Bueno, si no te importa que un cliente vea las facturas de otro...

    > Cómo seria en codigo TRANSAC poner un login a cada una?

    Primero crea el esquema en la base de datos, por ejemplo

    CREATE SCHEMA Esquema1 -- Esquema para el Cliente1

    Después crear el login y el user:

    CREATE LOGIN Cliente1 FROM ... (aquí el resto depende de la configuración)

    CREATE USER Cliente1 FOR LOGIN Cliente1 WITH DEFAULT_SCHEMA = Esquema1

    Concede permisos según sea necesario. Por ejemplo, para permiso de lectura:

    GRANT READ ON Schema::Esquema1 TO Cliente1

    Ahora ya puedes crear una tabla así:

    CREATE TABLE Esquema1.Facturas (...)

    y cuando escribas una SELECT sobre la tabla basta que hagas esto:

    SELECT * FROM Facturas WHERE...

    Fíjate que solo pone Facturas y no Esquema1.Facturas. Esto es gracias a que antes pusimos DEFAULT_SCHEMA=Esquema1 y por eso si el usuario logado es Cliente1 automáticamente accede a Esquema1.Facturas cuando haces un Select de Facturas. Si todos los clientes los configuras de manera similar, entonces puedes escribir todas las sentencias de tu programa poniendo solo "Facturas" en el nombre de la tabla, y automáticamente cada cliente accederá a sus facturas y no a las de nadie más.


    viernes, 15 de noviembre de 2019 7:52