Optimizar base de dato con 18 millones de registro

[ceysmar]

Buenas tengo un problema necesito optimizar una base de dato con 18 millones de registro en la tabla cliente estoy usando Access pero al hacer esta consulta:

Código:

OleDbConnection conexion = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=DataBase\\DataBase.mdb;Jet OLEDB:Database Password=xxxxxx");
            string comando = "SELECT COUNT(id) FROM clientes WHERE cedula=buscar";
            OleDbCommand existe = new OleDbCommand(comando, conexion);
            existe.Parameters.AddWithValue("buscar", buscar);
            conexion.Open();
            int consulta_existe = Convert.ToInt32(existe.ExecuteScalar());

            if (consulta_existe == 1)
            {
                textBox3.Text = Convert.ToString("si existe");
            }
            else {
                textBox3.Text = Convert.ToString("no existe");
            }

            conexion.Close();

Tarda aproximadamente 10 o 15 segundos en darme una respuesta, el código de arriba lo implemente para testear el rendimiento la verdad me tarda aproximadamente el tiempo mencionado en darme una respuesta la pregunta es cómo hago que el resultado sea instantáneo o en 2 segundo que me dicen ustedes… gracias

[Libras]

usa otro motor de base de datos :P

[ceysmar]

de echo he pensado usar mysql pero ese funciona en servidor lo que pasa es que estoy usando acess porque mi systema biene en varias versiones esta version es la basic y decidi que ese motor de database es la que mas se ajusta a la vercion tengo otra vercion que es servidor y caja y usa un servidor sql hee mi sistema es de administracion de empresas es un proyecto a la suerte lo hago sin interes solo quiero hacerlo y ya

[Libras]

para 18 millones de registros te recomiendo un motor de bases de datos mas potente no access......

[lauser]

Ufff.... opino como libras, Access,, se queda un poco cortito.....

[wwwmaster]

Access te tronara tarde o temprano con esa cantidad de registros, y probablemente no puedas recuperar tu informacion.

Respaldala o separala por años (aun cuando se trate de otra DB como Sql Server). Seguramente son datos historicos, no debieran convivir con los registros del año actual.

[Libras]

Iniciado por wwwmaster

Access te tronara tarde o temprano con esa cantidad de registros, y probablemente no puedas recuperar tu informacion.

Respaldala o separala por años (aun cuando se trate de otra DB como Sql Server). Seguramente son datos historicos, no debieran convivir con los registros del año actual.

Separar una base de datos de 18 millones de registros por años??? es broma verdad?? sql server puede soportar esa cantidad de registros en un solo filegroup sin problemas, ya que si quieres verte nice, puedes meter funciones de particion(hablando de sql server claro esta) y algunos filegroups..........pero 18 millones de registros es muy poco(claro que tomando en cuenta las caracteristicas del servidor)

[Carlangueitor]

No solo SQL Server, cualquier motor de bases de datos lo soporta sin problema.

[ceysmar]

bueno amigo caso cerrado en realidad para ser exactos no era 18 millones de registro eran 29.795.458 y si de escho para hacer una consulta a un id espesifico accees volaba como un trueno pero a la hora de deplegarme un listado con todo el registro... mejor no digo nada jajaj les comento esa base de dato fue un registro que tome del CNE (venezuela) los campos solo eran cedula nombre y apellido mi idea era que cuando alguien comprara un articulo y es nuevo en la tiemda porque registrarlo ? si ya estaria pre cargado sus datos ? ya que el CNE posee el registro total de todo venezolano con cedula en venezuela asi que no habria venezolano con cedula que no estaria registrado hay :D pero en fin renuncie necesito trabajar con acees ya que es el motor mas eficiente para el uso que pienzo darle al sistema y es mas facil para el usuario instalar el sistema si usara sql serve pos tendria que haber instalado serve antes asi que a comodida del cliente acess..... ya que cualquer conputadora tiene acess hoy dia

[Libras]

Iniciado por ceysmar

bueno amigo caso cerrado en realidad para ser exactos no era 18 millones de registro eran 29.795.458 y si de escho para hacer una consulta a un id espesifico accees volaba como un trueno pero a la hora de deplegarme un listado con todo el registro... mejor no digo nada jajaj les comento esa base de dato fue un registro que tome del CNE (venezuela) los campos solo eran cedula nombre y apellido mi idea era que cuando alguien comprara un articulo y es nuevo en la tiemda porque registrarlo ? si ya estaria pre cargado sus datos ? ya que el CNE posee el registro total de todo venezolano con cedula en venezuela asi que no habria venezolano con cedula que no estaria registrado hay :D pero en fin renuncie necesito trabajar con acees ya que es el motor mas eficiente para el uso que pienzo darle al sistema y es mas facil para el usuario instalar el sistema si usara sql serve pos tendria que haber instalado serve antes asi que a comodida del cliente acess..... ya que cualquer conputadora tiene acess hoy dia

Muy buena idea, pero nada mas una cosa, dices que tu base tiene todos los registros a que dia???? si bajo esa base de datos y mañana se agrega alguien ese alguien aparece??? Y sobre lo de access, sigo diciendo que es una aplicacion para oficina, no me fiaria de alguien que me venda un sistema de informacion en access...........digo es mi punto de vista......

[ceysmar]

Iniciado por Libras

Muy buena idea, pero nada mas una cosa, dices que tu base tiene todos los registros a que dia???? si bajo esa base de datos y mañana se agrega alguien ese alguien aparece??? Y sobre lo de access, sigo diciendo que es una aplicacion para oficina, no me fiaria de alguien que me venda un sistema de informacion en access...........digo es mi punto de vista......

no tiene o sea la base de dato del CNE la llenan cada cierto periodo no todo el tiempo o a diario y pues tampoco es que tiene que estar exactamente todos pero si la mayoria a la hora de comprar algo ahorraria trabajo de registrar cliente a ciertas persona porque ya estarian preincrita con respecto a lo de acees estoy de acuerdo que es de oficina pero que es lo peor que puede pasar ? o sea a la ora de perdida de dato asi porque si solo no se pues es mi primera ves que trabajo con acees solo me adacte a lo mas comodo para el usuario pero considero que si se trata de perdida de informacion debe ser por intervencion humana o algun virus pero no porque acees la valla a cagar tampoco va ser un sistema que guarde mucha informacion no creo que haya ninguna perdida en caso tal de que borren la base de dato el sistema hace respaldo a diario asi que no habria mucho problema yo creo que depende del sistema uno adacta su base de dato de echo mi sistema posee varias verciones la que usa un motor de dato sql es espesifico y va dirigido a otro tipos de cliente el mismo sistema pero varia segun la necesidad cuando me toca conectar el sistema en red hay es cuando uso la vercion con data base sql ya que la base de dato estaria en servidor

[Libras]

pero para que tener 18 millones de registros de clientes cuando solo tienes 20?? eso es un desperdicio de espacio de recursos que no le veo sentido(del lado de la administracion de la base de datos) seria mejor ir llenando la base de datos conforme sea el uso que no???

[ceysmar]

Iniciado por Libras

pero para que tener 18 millones de registros de clientes cuando solo tienes 20?? eso es un desperdicio de espacio de recursos que no le veo sentido(del lado de la administracion de la base de datos) seria mejor ir llenando la base de datos conforme sea el uso que no???

Si hermano es verdad me resigne pero bueno es que me gusta hacerle las cosas aun mas fáciles a los usuarios por eso tenia planeado eso y aunque una tienda tenga solo 20 clientes el sistema es usado a nivel nacional quizás uno tenga mas cliente que otro y ya estando registrado pues es un trabajo menos para el usuario o cajero de todas ya deje eso normal ir llenando a medida que vallan llegando así es mas óptimo le elimine un 1gb de datos a la db

[Libras]

Iniciado por ceysmar

Si hermano es verdad me resigne pero bueno es que me gusta hacerle las cosas aun mas fáciles a los usuarios por eso tenia planeado eso y aunque una tienda tenga solo 20 clientes el sistema es usado a nivel nacional quizás uno tenga mas cliente que otro y ya estando registrado pues es un trabajo menos para el usuario o cajero de todas ya deje eso normal ir llenando a medida que vallan llegando así es mas óptimo le elimine un 1gb de datos a la db

Ok entiendo tu preocupacion, pero cuanto tiempo perderias capturando los datos de los clientes? Lo mas optimo es que cada sucursal capture sus propios clientes, porque la verdad a mi no me interesa tener los datos de "John Deer" si ni siquiera se quien es :P

[Kritik]

Sencillamente... aunque el tema de tener los datos del CNE es bastante útil para no tener que dar de alta a ningún usuario, pues sus datos están en esa tabla... a veces es mejor renunciar a esa información, ya que lo único que vas a copiar es el nombre y apellidos. Y tener 30 millones de registros te va a sobrecargar el sistema... cuando luego en realidad no vas a llegar ni a 5000 de esos 30 millones. El uso que vas a darle a esa información es mínimo, y por eso no merece la pena copiar todo el listado del CNE.

Otra solución sería:

Igual que tienes acceso a todo ese listado... no puedes acceder a él en tiempo de ejecución, sin tener que descargarlo, sino que tu programa consulte directamente en el CNE, y no en la información descargada? Así además no tendrías que preocuparte por actualizar los datos.

Access no está preparado para tener tantos registros. Es un motor de bases de datos diseñado para escritorio, a modo de aplicación y no a modo de servicio.

Access es un muy buen sistema de bases de datos para tener relativamente pocos registros. Y con pocos no me refiero a 100-200... sino que por ejemplo, 5.000 registros los maneja bastante bien. Y un cliente que compra este tipo de aplicación pequeña hecha en Access dudo mucho que llegue nunca a tener esa cantidad. Y si la llega a tener tendría tantos ingresos que debería de plantearse un sistema de bases de datos más potente.

Por muchos azotes que le pegues a un caballo nunca llegará a los 100km/h.

[ceysmar]

Iniciado por Kritik

Sencillamente... aunque el tema de tener los datos del CNE es bastante útil para no tener que dar de alta a ningún usuario, pues sus datos están en esa tabla... a veces es mejor renunciar a esa información, ya que lo único que vas a copiar es el nombre y apellidos. Y tener 30 millones de registros te va a sobrecargar el sistema... cuando luego en realidad no vas a llegar ni a 5000 de esos 30 millones. El uso que vas a darle a esa información es mínimo, y por eso no merece la pena copiar todo el listado del CNE.

Otra solución sería:

Igual que tienes acceso a todo ese listado... no puedes acceder a él en tiempo de ejecución, sin tener que descargarlo, sino que tu programa consulte directamente en el CNE, y no en la información descargada? Así además no tendrías que preocuparte por actualizar los datos.

Access no está preparado para tener tantos registros. Es un motor de bases de datos diseñado para escritorio, a modo de aplicación y no a modo de servicio.

Access es un muy buen sistema de bases de datos para tener relativamente pocos registros. Y con pocos no me refiero a 100-200... sino que por ejemplo, 5.000 registros los maneja bastante bien. Y un cliente que compra este tipo de aplicación pequeña hecha en Access dudo mucho que llegue nunca a tener esa cantidad. Y si la llega a tener tendría tantos ingresos que debería de plantearse un sistema de bases de datos más potente.

Por muchos azotes que le pegues a un caballo nunca llegará a los 100km/h.

muy buena tu respuesta es correcto pero bueno como aveces busco darle facilidad a los usuario y es correcto una empresa com mas de 5000 clientes debe plantearce un sistema mas potente la verdad es que mi sistema es facimente modificable en cuanto a base de dato solo con cambiar unos codigo pasaria de usar base de dato de acces a usar base de dato de mysql la verdad tengo pensado hacer dos verciones con diferentes motor de base de dato