Foro oficial de SQL

Buenas Noches Muchachos

Quiero aprender sql y bases de datos, que me recomiendan revisar primero ? y si me pueden indicar algún lado donde haya buenos tutoriales o cosas así para comenzar a darle con juicio se los agradecería mucho
 
Hola
espero me puedan ayudar; tengo una tabla que en una de sus columnas lleva el numero de cedula de unos usuarios, necesito adicionar al numero de cedula las letras AHJ al numero de cedula existente
ejemplo; en la tabla sale el numero de cedula 79.666.666 y debe quedar con AHJ79.666.666 son como 5000 usuarios.
agradezco la gran ayuda
 
Buenas les traigo la siguiente pregunta relacionada con las vistas y procedimientos almacenados.

Personalmente yo nunca le he encontrado mucha utilidad a esas dos herramientas que tienen practicamente todos los gestores de bases de datos relacionales por la sencilla razon de que practicamente cualquier cosa que se haga en vistas o procedimientos almacenados se pueden hacer tambien por medio de una sentencia en el codigo de la aplicacion que va a hacer uso de la base de datos. Por este motivo me gustaria que otros usuarios opinaran acerca de cual puede ser la razon por la cual una sentencia deba ser escrita como vista o como procedimiento almacenado
 
Buenas les traigo la siguiente pregunta relacionada con las vistas y procedimientos almacenados.

Personalmente yo nunca le he encontrado mucha utilidad a esas dos herramientas que tienen practicamente todos los gestores de bases de datos relacionales por la sencilla razon de que practicamente cualquier cosa que se haga en vistas o procedimientos almacenados se pueden hacer tambien por medio de una sentencia en el codigo de la aplicacion que va a hacer uso de la base de datos. Por este motivo me gustaria que otros usuarios opinaran acerca de cual puede ser la razon por la cual una sentencia deba ser escrita como vista o como procedimiento almacenado

Yo pocon de bases de datos pero entiendo esto:

La ventaja es que estos procedimientos se ejecutan directamente sobre el motor de la base de datos, haciéndolos mas rápidos ya que los datos no tienen que ser trasmitidos a otra aplicación o servidor para ser procesados sino que regresan solo los datos importantes (el resultado) del proceso.

mirese esta articulo

http://en.wikipedia.org/wiki/Stored_procedure
 
Buenas les traigo la siguiente pregunta relacionada con las vistas y procedimientos almacenados.

Personalmente yo nunca le he encontrado mucha utilidad a esas dos herramientas que tienen practicamente todos los gestores de bases de datos relacionales por la sencilla razon de que practicamente cualquier cosa que se haga en vistas o procedimientos almacenados se pueden hacer tambien por medio de una sentencia en el codigo de la aplicacion que va a hacer uso de la base de datos. Por este motivo me gustaria que otros usuarios opinaran acerca de cual puede ser la razon por la cual una sentencia deba ser escrita como vista o como procedimiento almacenado

Yo hasta ahora no he tenido la oportunidad de entenderme con esas cosas gracias a que mi pensamiento es del tipo "la base de datos para mi no es más que un recipiente que gestiona mis datos, Listar, Crear, Actualizar y Borrar" y si a mucho cositas que se hacen en la misma consulta como un conteo o parecidos.

Pero si mal no recuerdo, ese pensamiento es para cuando uno quiere que su APP cambie fácilmente de Base de Datos y creo que la cosa así está bien.

El cuento es que quien se monte en un Oracle o un SQL Server... pues dudo mucho que se cambien de motor tan fácilmente y entonces con es llegan los procedimientos almacenados, centinelas y demás cosillas que estos motores traen.

La utilidad de todo eso está en que como lo dijo el compañero Dak, los datos no tienen necesidad de viajar a las APP, se ejecutan más rápido en el motor y todo eso conlleva a un ahorro de tiempo por parte de la APP en responder y un ahorro en esfuerzo por parte de la maquina en procesar todo eso. Pero esas son cosas en las que realmente le vemos la efectividad en productos de Mega Empresas como por ejemplo los sistemas de facturación de un EMCALI, ETB y cosas así.

Creo que por acá nos puede ayudar el gurú de .NET, en darnos explicaciones más exactas y amplias de las utilidades de los procedimientos almacenados.

El cuento y para resumir, es que es bueno saber que existen y por lo menos de saber leer esas cosas y si no ser capaz de crear uno, por lo menos de leerlos y saber modificarles cositas y ahí poco a poco se va aprendiendo a manejar eso :)

El caso de las vistas para mi es algo distinto, porque para mi han sido espectaculares cuando las consultas que se deben realizar son algo pesadas para el motor, entonces ahí entran los conceptos de vistas materializadas (que son las vistas que arman una tabla con la consulta y mantienen actualizadas... o algo así)
 
Yo pocon de bases de datos pero entiendo esto:

La ventaja es que estos procedimientos se ejecutan directamente sobre el motor de la base de datos, haciéndolos mas rápidos ya que los datos no tienen que ser trasmitidos a otra aplicación o servidor para ser procesados sino que regresan solo los datos importantes (el resultado) del proceso.

mirese esta articulo

http://en.wikipedia.org/wiki/Stored_procedure

Si, esa es una de las ventajas pero yo me pregunto que tan ventajoso puede ser eso. Si bien el el lenguaje PL/SQL tiene sus variantes como PL/PHP y PL/JAVA que pueden hacer mas interesante el asunto yo igual sigo con mi duda por ejemplo de si vale la pena gastarle tiempo a crear un procedimiento almacenado para traer un registro de por decir algo 10 columnas con 5 joins o simplemente hacerlo en el codigo con la ventaja de que si se hace en el codigo haciendo uso de algun framework de abstraccion se puede tener compatibilidad con varios gestores mientras que el procedimiento toca darle compatibilidad manualmente.

Respecto a las vistas no se porque no me alcanzo a imaginar como hacen para ayudar a dar mayor velocidad a una consulta si practicamente son una copia de una tabla que tambien va a estar ocupando espacio

Esta duda me salio porque en la empresa donde estoy todos los dias trabajo con big data, en un dia tranquilamente se pueden hacer conteos de 50 millones de registros o mas junto con las transacciones que se deben hacer para poner toda esta informacion a disposicion de los usuarios para que generen sus informes y pues en el momento me encuentro haciendo una integracion de 8 servidores de bases de datos que se encuentran distribuidos geograficamente (puro desorden de la empresa) en un solo aplicativo y al momento de hacer una de las consultas un companero me recomendo hacer uso de PL/SQL (para no complicarme tanto la vida) pero preferi hacerlo en un simple SQL, al final me quedo una sentencia de 30 lineas y casi 8 Joins y pues por el momento sigo con la duda de si deberia intentar pasarlo a PL/SQL y sobretodo si vale la pena pasarlo

EDITO: Ahora que me acuerdo una vez le encontre algo de utilidad al PL/SQL, actualmente tengo un procedimiento en un servidor que crea una copia de una de las tablas principales y mas grandes de la base de dato, copia todos los registros y luego vuelve a generar los indices, posteriormente borra la tabla desde la cual se hizo el copiado y cambia el nombre de la tabla temporal por el nombre definitivo dando por finalizado el proceso. Casos como estos son los que me parece que si deben ser escritos si o si como procedimiento almacenado o sera que me estoy equivocando y estoy muy confundido? o_O
 
Última edición:
Si, esa es una de las ventajas pero yo me pregunto que tan ventajoso puede ser eso. Si bien el el lenguaje PL/SQL tiene sus variantes como PL/PHP y PL/JAVA que pueden hacer mas interesante el asunto yo igual sigo con mi duda por ejemplo de si vale la pena gastarle tiempo a crear un procedimiento almacenado para traer un registro de por decir algo 10 columnas con 5 joins o simplemente hacerlo en el codigo con la ventaja de que si se hace en el codigo haciendo uso de algun framework de abstraccion se puede tener compatibilidad con varios gestores mientras que el procedimiento toca darle compatibilidad manualmente.

PL\SQL resulta muy útil para hacer cosas del lado del servidor como el ejemplo que usted pone donde se esta modificando las tablas, por ahi estan los commint, savepoint, los rollbacks y montón de otras herramientas que tiene el lenguaje....

IMO Dependiendo del caso y como se haga; PL\SQL se luce para darle un pre procesamiento y manipular los datos.... Si de todas formas solo consulta, le funciona, es sostenible para el desarrollo de la base y le da buenos tiempos por ahí es la cosa; aunque haga el ejercicio de hacerlo en PL\SQL a ver como le va con memoria y tiempos...

Respecto a las vistas no se porque no me alcanzo a imaginar como hacen para ayudar a dar mayor velocidad a una consulta si practicamente son una copia de una tabla que tambien va a estar ocupando espacio

Las vistas no necesariamente van a agregar velocidad, por el contrario el motor primero llama a la declaración de la vista y luego la ejecuta (Las vistas Oracle no ocupan espacio*); Lo que al final no es que tome mucho más tiempo, pero si resulta más practico que buscar una consulta de varias lineas.

Detallitos que yo le veo a las vistas:
*Practicas
*Se puede poner seguridad: ocultando de donde salen originalmente los datos, mostrando solo lo que se necesite mostrar; Permiten entregar la información mas molidita
*Pueden ser usadas por otros lenguajes para crear objetos directamente de ellas
*Permiten editar (motor, condiciones de creación, PL\SQL)

Esta duda me salio porque en la empresa donde estoy todos los dias trabajo con big data, en un dia tranquilamente se pueden hacer conteos de 50 millones de registros o mas junto con las transacciones que se deben hacer para poner toda esta informacion a disposicion de los usuarios para que generen sus informes y pues en el momento me encuentro haciendo una integracion de 8 servidores de bases de datos que se encuentran distribuidos geograficamente (puro desorden de la empresa) en un solo aplicativo y al momento de hacer una de las consultas un companero me recomendo hacer uso de PL/SQL (para no complicarme tanto la vida) pero preferi hacerlo en un simple SQL, al final me quedo una sentencia de 30 lineas y casi 8 Joins y pues por el momento sigo con la duda de si deberia intentar pasarlo a PL/SQL y sobretodo si vale la pena pasarlo

No se si estas trabajando con Big data pero si lo estas abordando con bases convencionales y joins no lo es.... De Big data aparte de ser otro termino de mercado, 3 cosas que siempre se habla: cantidad/velocidad/variedad de los datos.

Respecto al cambio intente hacerlo cuando tenga tiempo pero si lo esta haciendo con joins seguramente por ahi es.... Pero haga el ejercicio...

*Aparte de la declaración
 
Última edición:
Buenas les traigo la siguiente pregunta relacionada con las vistas y procedimientos almacenados.

Personalmente yo nunca le he encontrado mucha utilidad a esas dos herramientas que tienen practicamente todos los gestores de bases de datos relacionales por la sencilla razon de que practicamente cualquier cosa que se haga en vistas o procedimientos almacenados se pueden hacer tambien por medio de una sentencia en el codigo de la aplicacion que va a hacer uso de la base de datos. Por este motivo me gustaria que otros usuarios opinaran acerca de cual puede ser la razon por la cual una sentencia deba ser escrita como vista o como procedimiento almacenado

Bueno, en al menos SQL Server las vistas lo que hacen es lo que le dice NSlaver, abstraen los detalles internos de como se obtiene la informacion... falcilmente una vista que te trae informacion de 10 o 15 tablas la obtienes con un simpre select * from VW_Datos (por ejemplo) en vez de estar haciendo todos los join necesarios.... ademas, imaginate que necesites los datos que obtienes con esa vista, para hacer una mas compleja.... ¿cual seria mas facil de hacer y se podria reutilizar?

  • Una consulta con join de 20 tablas
  • Una vista y 5 tablas (yo optaria por esta por simple comodidad).

En este caso suponiendo que la vista es una consulta que se utilice en muchas situaciones... ahi mas o menos es donde entraria basicamente el uso de la vista, tener consultas recurrentes de datos con un tamaño considerable, y en vez de escribir toda la consulta siempre, solo hacer una llamada a la vista.

En el caso de los procedimientos almacenados es otra cosa.... estos si ayudan al performance, dado que, como es una consulta basada en un query que no cambia con cada ejecucion la primera vez que se corre es cuanto mas cuesta al moto de base de datos, ya que tiene que crear un plan de ejecucion. Que tiene de bueno esto?.. simple!!... ese plan de ejecucion se almacena y el motor todas las veces que tenga que realizar esa consulta no tiene que hacer un plan de ejecucion nuevo para obtener los datos (cosa que si hacen las consultas directas y las vistas basadas en consultas directas), por lo que el tiempo de respuesta se puede ver muy reducidos si se hace buen uso de los procedimientos almacenados.

PD: Si lo que quiere es obtener un mejor tiempo en las consultas le recomiendo que analices las consultas tambien con el Query plan de tu motor de base de datos, ya que muchas veces te dice donde hay detalles que pueden hacer que tu consulta sea mas eficiente y que puede hacer que sea mas lenta.


SuerteX :)
 
  • Me gusta
Reacciones: [sC+].V0DK4N
Bueno, en al menos SQL Server las vistas lo que hacen es lo que le dice NSlaver, abstraen los detalles internos de como se obtiene la informacion... falcilmente una vista que te trae informacion de 10 o 15 tablas la obtienes con un simpre select * from VW_Datos (por ejemplo) en vez de estar haciendo todos los join necesarios.... ademas, imaginate que necesites los datos que obtienes con esa vista, para hacer una mas compleja.... ¿cual seria mas facil de hacer y se podria reutilizar?

  • Una consulta con join de 20 tablas
  • Una vista y 5 tablas (yo optaria por esta por simple comodidad).

En este caso suponiendo que la vista es una consulta que se utilice en muchas situaciones... ahi mas o menos es donde entraria basicamente el uso de la vista, tener consultas recurrentes de datos con un tamaño considerable, y en vez de escribir toda la consulta siempre, solo hacer una llamada a la vista.

En el caso de los procedimientos almacenados es otra cosa.... estos si ayudan al performance, dado que, como es una consulta basada en un query que no cambia con cada ejecucion la primera vez que se corre es cuanto mas cuesta al moto de base de datos, ya que tiene que crear un plan de ejecucion. Que tiene de bueno esto?.. simple!!... ese plan de ejecucion se almacena y el motor todas las veces que tenga que realizar esa consulta no tiene que hacer un plan de ejecucion nuevo para obtener los datos (cosa que si hacen las consultas directas y las vistas basadas en consultas directas), por lo que el tiempo de respuesta se puede ver muy reducidos si se hace buen uso de los procedimientos almacenados.

PD: Si lo que quiere es obtener un mejor tiempo en las consultas le recomiendo que analices las consultas tambien con el Query plan de tu motor de base de datos, ya que muchas veces te dice donde hay detalles que pueden hacer que tu consulta sea mas eficiente y que puede hacer que sea mas lenta.


SuerteX :)

Muy buena la explicacion, ahora me siento un poco mas enfocado sobre cuando se deben usar procedimientos almacenados o vistas
 
Buenas tardes, espero que alguien me pueda ayudar con el problema que tengo, ya que no estoy muy puesto en sql, tengo la siguiente consulta realizada en una aplicación basada en Access:

SELECT
DateName(m,PartesDiarios.FechaInicial) Mes, Left(Convert(Varchar,(Partes_Diarios_Conduccion.HoraFinalConduccion)-(Partes_Diarios_Conduccion.HoraInicioConduccion),108),5) Horas,
Partes_Diarios_Conduccion.Conductor1 Conductor1, Partes_Diarios_Conduccion.Conductor2 Conductor2
FROM
PartesDiarios PartesDiarios
LEFT JOIN PartesDiariosConduccion Partes_Diarios_Conduccion ON ( PartesDiarios.AnoRegistro=Partes_Diarios_Conduccion.AnoRegistroPartes AND PartesDiarios.NRegistro=Partes_Diarios_Conduccion.NRegistroPartes )
WHERE
( (UPPER(Partes_Diarios_Conduccion.Seccion) LIKE 'VERDURAS %') )
ORDER BY
Month(PartesDiarios.FechaInicial) ASC, Partes_Diarios_Conduccion.Conductor1 ASC

Consulta que me saca la siguiente tabla:

Mes Horas Conductor1 Conductor2
Enero 2:00 1 2
Enero 0:40 3 4
Enero 2:00 3 5
Enero 1:00 6 2
Enero 0:54 6 5
Febrero 1:15 6 2
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 0:30 6 2
Febrero 0:30 6 5
Marzo 1:00 6 2
Marzo 1:00 5 6
Marzo 1:00 5 8
Marzo 1:05 5 8
Marzo 1:00 5 8
Marzo 1:10 5 8
........

Lo que quisiera poder sacar en la consulta, son estos mismo datos, pero que me salga sólo una columna de conductor y la columna de hora sume el tiempo que está como conductor 1 y 2 y al mes, es decir, algo como esto:

Mes Horas Conductor
Enero 2:00 1
Enero 3:00 2
Enero 2:40 3
Enero 0:40 4
Enero 2:54 5
Enero 1:54 6
Febrero ........

No sé si me he explicado bien, un saludo y gracias.
 
Buenas tardes, espero que alguien me pueda ayudar con el problema que tengo, ya que no estoy muy puesto en sql, tengo la siguiente consulta realizada en una aplicación basada en Access:

SELECT
DateName(m,PartesDiarios.FechaInicial) Mes, Left(Convert(Varchar,(Partes_Diarios_Conduccion.HoraFinalConduccion)-(Partes_Diarios_Conduccion.HoraInicioConduccion),108),5) Horas,
Partes_Diarios_Conduccion.Conductor1 Conductor1, Partes_Diarios_Conduccion.Conductor2 Conductor2
FROM
PartesDiarios PartesDiarios
LEFT JOIN PartesDiariosConduccion Partes_Diarios_Conduccion ON ( PartesDiarios.AnoRegistro=Partes_Diarios_Conduccion.AnoRegistroPartes AND PartesDiarios.NRegistro=Partes_Diarios_Conduccion.NRegistroPartes )
WHERE
( (UPPER(Partes_Diarios_Conduccion.Seccion) LIKE 'VERDURAS %') )
ORDER BY
Month(PartesDiarios.FechaInicial) ASC, Partes_Diarios_Conduccion.Conductor1 ASC

Consulta que me saca la siguiente tabla:

Mes Horas Conductor1 Conductor2
Enero 2:00 1 2
Enero 0:40 3 4
Enero 2:00 3 5
Enero 1:00 6 2
Enero 0:54 6 5
Febrero 1:15 6 2
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 1:00 6 7
Febrero 0:30 6 2
Febrero 0:30 6 5
Marzo 1:00 6 2
Marzo 1:00 5 6
Marzo 1:00 5 8
Marzo 1:05 5 8
Marzo 1:00 5 8
Marzo 1:10 5 8
........

Lo que quisiera poder sacar en la consulta, son estos mismo datos, pero que me salga sólo una columna de conductor y la columna de hora sume el tiempo que está como conductor 1 y 2 y al mes, es decir, algo como esto:

Mes Horas Conductor
Enero 2:00 1
Enero 3:00 2
Enero 2:40 3
Enero 0:40 4
Enero 2:54 5
Enero 1:54 6
Febrero ........

No sé si me he explicado bien, un saludo y gracias.
Facil.... quite: , Partes_Diarios_Conduccion.Conductor2 Conductor2


SuerteX :)
 
Pues cómo yo lo veo es más para el reuso de consultas y el encapsulamiento de programas como los Jobs o SSIS éso cómo ejemplo de uso de esos procedimientos

Enviado desde mi C6903 mediante Tapatalk
 
Que tal compas; revisando un poco más a detalle el tema de SQL me he encontrado con una serie de interrogantes; haber si me podeis echar una mano.

1.- ¿Existe algún problema si instalo en mi servidor SQL 2008 Enterprise en Inglés? y en mis equipos clientes el SQL Enterprise en español. Puede haber algún tipo de conflicto en lectura de store procedure o sintaxis? Quizas la duda que me surge de inmediato es en la lectura de la fecha pero creo (corrijanme si me equivoco) esto lo puedo remediar ejecutando en mi cliente
SET DATEFORMAT <mdy> o <dmy> según corresponda.

2.- ¿Cómo se maneja el tema de licenciamiento en ambientes virtuales? Hasta donde tengo entendido debo contar con una licencia Servidor (Por procesador o core) y otra Cliente. Por tanto; basta que mi Servidor físico tenga licenciado toda la cacapidad de procesadores disponibles para poder tener varios servidores virtualizados con SQL sin tener el problema de licencias para ellas?

3.- No he realizado aún una réplica pero estoy a días de tener que realizarlo dado que la BD actual no cuenta con una; por tanto leyendo un poco sobre el tema; me surgieron las siguientes interrogantes

Respecto al tema de rélicas; entiendo que dicha réplica me creará una BD identica a la de Producción y de acuerdo a las configuraciones dadas se irá actualizando gradualmente. Existe algún riesgo en caso se presente algún problema al configurar mi réplica? Ya que esto lo trabajo directamente con la BD de Producción y claro teniendo previamente un backup actualizado. Por otra parte mi BD de Producción que es un SQL 2008 Enterprise (English) tiene sólo Service Pack1 de la misma forma; es transparente si realizó la instalación del parche a SP2 o que consideraciones debería tener previamente. Quizas primero realizar la réplica y empezar actualizar una réplica para que posteriormente se actualice en la principal?

4.- Estoy por recibir el control de todas las BD de una empresa; por lo que el DBA actual me estará haciendo entrega de todas las credenciales (de las cuales haré el cambio de contraseñas respectivo) ¿Qué consideraciones se debería tener al momento de recibir la potestad de una BD anteriormente administrada por otro DBA?
Esto lo consulto a manera de experiencia profesional cuando les tocó estar en una situación parecida; con el fin de que no quede algo suelto por ahi al momento de recibir la administración de las BD.

Espero puedan comentar un poco de sus experiencias.

Saludos,
 
Que tal compas; revisando un poco más a detalle el tema de SQL me he encontrado con una serie de interrogantes; haber si me podeis echar una mano.

1.- ¿Existe algún problema si instalo en mi servidor SQL 2008 Enterprise en Inglés? y en mis equipos clientes el SQL Enterprise en español. Puede haber algún tipo de conflicto en lectura de store procedure o sintaxis? Quizas la duda que me surge de inmediato es en la lectura de la fecha pero creo (corrijanme si me equivoco) esto lo puedo remediar ejecutando en mi cliente
SET DATEFORMAT <mdy> o <dmy> según corresponda.

No importa por que en la instalación por lo general toma la del OS, se puede cambiar después de la instalación y se puede especificar a nivel de usuario... también mire el separador de miles . o ,

2.- ¿Cómo se maneja el tema de licenciamiento en ambientes virtuales? Hasta donde tengo entendido debo contar con una licencia Servidor (Por procesador o core) y otra Cliente. Por tanto; basta que mi Servidor físico tenga licenciado toda la cacapidad de procesadores disponibles para poder tener varios servidores virtualizados con SQL sin tener el problema de licencias para ellas?

Aqui un link de MS: https://www.microsoft.com/licensing/about-licensing/briefs/virtual-licensing.aspx

Al final de cuentas depende de la versión, mejor asesorarse directamente con alguien de MS; Su empresa debe tener algún contacto/asesor y seguro le mandan/contactan con alguien que lo saque de dudas en un brinco.

3.- No he realizado aún una réplica pero estoy a días de tener que realizarlo dado que la BD actual no cuenta con una; por tanto leyendo un poco sobre el tema; me surgieron las siguientes interrogantes
Respecto al tema de rélicas; entiendo que dicha réplica me creará una BD identica a la de Producción y de acuerdo a las configuraciones dadas se irá actualizando gradualmente. Existe algún riesgo en caso se presente algún problema al configurar mi réplica? Ya que esto lo trabajo directamente con la BD de Producción y claro teniendo previamente un backup actualizado. Por otra parte mi BD de Producción que es un SQL 2008 Enterprise (English) tiene sólo Service Pack1 de la misma forma; es transparente si realizó la instalación del parche a SP2 o que consideraciones debería tener previamente. Quizas primero realizar la réplica y empezar actualizar una réplica para que posteriormente se actualice en la principal?

Toque los temas por aparte primero deje todo actualizado a las mismas versiones antes de comenzar con el tema de la réplicas; las cosas pueden terminar peor en una actulizacion que en una replica; Tenga un Full Bakcup

4.- Estoy por recibir el control de todas las BD de una empresa; por lo que el DBA actual me estará haciendo entrega de todas las credenciales (de las cuales haré el cambio de contraseñas respectivo) ¿Qué consideraciones se debería tener al momento de recibir la potestad de una BD anteriormente administrada por otro DBA?
Esto lo consulto a manera de experiencia profesional cuando les tocó estar en una situación parecida; con el fin de que no quede algo suelto por ahi al momento de recibir la administración de las BD.

Espero puedan comentar un poco de sus experiencias.
Saludos,

No me ha tocado pero me basaría con en guias/procedimientos de auditoria que encuentra con google
 
Buenas, necesito algo de ayuda con PostgreSQL a ver si hay alguien por aqui que me pueda colaborar

Actualmente la empresa cuenta con 6 servidores SQL distribuidos por territorio nacional, todos con el mismo modelo relacional de DB y el mismo aplicativo (un desorden completo) y actualmente me pusieron en la tarea de consolidar la informacion de todos esos servidores mediante un aplicativo hecho en PHP. Actualmente lo que estoy haciendo por medio de instancias de los servidores y una capa de abstraccion dedicada nada mas a las consultas hacer una consulta X en todos los servidores y obtener los resultados y almacenarlos como objetos. El unico y gran problema es que la informacion tiende a desordenarse y por ejemplo hay registros que se duplican en los servidores y deben ser agrupados y eso hecho por php... mejor dicho se crece el enano.

Se me ocurrio hacer uso de la utilidad DBLINK de PostgreSQL pero hay serios inconvenientes, mi idea es mas o menos la siguiente: Tener un servidor "maestro" en el cual se encuentren todas las consultas del aplicativo a modo de procedimiento almacenado pero cada procedimiento debe hacer lo siguiente:

-Comprobar que haya un enlace de red exitoso hacia el servidor, en caso de no haberlo debe encapsular un error pero aun asi seguir consultando en el resto de servidores y mostrar el resultado, por medio de php se coge el error encapsulado y se le hace saber al usuario que la informacion puede no ser 100% veras debido al inconveniente con el servidor sin conexion

-Preferiblemente y por tiempos de respuesta si lanzo una consulta X deberia de poder hacerse esa consulta en modo paralelo en todos los servidores, en caso de que esto no se pueda no hay problema, solo es una idea con el fin de ahorrar tiempo de ejecucion

Ademas todos los tutoriales, ejemplos y lecturas que he visto acerca de DBLINK son con 2 DBs, la local y a la que van a conectar asi que me quedan mis dudas de si DBLINK soporta conexiones a mas de 2 bases de datos simultaneas

Alguien me puede colaborar a desenredarme un poco?
 
Lo primero que debe considerar es la duplicidad de informacion, y por otro lado ver como centralizas los datos o contemplar la opcion de NSlaver, ya que seria mas facil hacerlo, aunque leyendo detenidamente hay que hacer un buen trabajo, ya que las informaciones de las DB son diferentes aunque la estructura sea la misma.


SuerteX :)
 

Los últimos temas