Hola,
Voy a hacer un proceso de facturacion y necesito asegurar que nadie
pueda facturar en el mismo momento que yo.
Necesito bloquear una tabla de manera que nadie pueda hacer un insert,
update o delete, solo pueda leer de la tabla pero nada mas hasta que
termine el trabajo.
¿CUAL SERIA EL
> Hola,
>
> Voy a hacer un proceso de facturacion y necesito asegurar que nadie
> pueda facturar en el mismo momento que yo.
> Necesito bloquear una tabla de manera que nadie pueda hacer un insert,
> update o delete, solo pueda leer de la tabla pero nada mas hasta que
> termine el trabajo.
>
> ¿CU
2016-04-19 20:02 GMT+02:00 Gilberto Castillo :
>> ¿CUAL SERIA EL TIPO DE BLOQUEO MAS ADECUADO?
> Ninguno, si quieres hacer eso has las transacciones serializable y listo.
IRL eso no es tan sencillo, hacer las transacciones serializables te
garantiza que de hacerlas lo haras bien, pero tienes que e
2016-04-19 19:55 GMT+02:00 Kernel :
> Voy a hacer un proceso de facturacion y necesito asegurar que nadie pueda
> facturar en el mismo momento que yo.
> Necesito bloquear una tabla de manera que nadie pueda hacer un insert,
> update o delete, solo pueda leer de la tabla pero nada mas hasta que term
Kernel escribió:
> Hola,
>
> Voy a hacer un proceso de facturacion y necesito asegurar que nadie pueda
> facturar en el mismo momento que yo.
¿cuál es la razón para esta restricción?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, T
Que tal buenas tardes.
Me gustaria su opinion sobre lo siguiente. Hace varios años que se hizo un
sistema para logistica de material. Con el paso de los años, dos tablas
principales crecieron al grado de tener millones de registros, una es la
que representa cada caja de material y la otra es los m
Ivan Perales M. escribió:
> Cuando se hace una consulta para un cliente pequeño en esas tablas, el
> tiempo del query es mucho mayor a que si solo buscara en los registros
> propios del cliente y esto es obvio, es por que tambien busca entre los
> registros de los otros clientes.
¿no tienes un ín
Hola Ivan, te comento entre lineas
On 19/04/16 16:07, Ivan Perales M. wrote:
Que tal buenas tardes.
Me gustaria su opinion sobre lo siguiente. Hace varios años que se
hizo un sistema para logistica de material. Con el paso de los años,
dos tablas principales crecieron al grado de tener millone
Hola Ivan
PostgreSQL esta en capacidad de forma 'automática' los diferentes tablas
que hacen parte de la un partición, el tema del procedimiento es que si
diseña bien la clave de partición la definición del Procedimiento es
sencillo y de mantenimiento muy espaciado en el tiempo (incluso puede s
Si tiene indices, la tabla de movimientos apunta a la caja de material, la
caja de material apunta al material en sí y el material al cliente.
Todo está bien indexado, se ejecutan vacums periodicamente, cada año se
realiza un drop y se vuelve a cargar la información. El sistema no es
grande, es peq
Te recomiendo olvidarte de todo lo que escribiste y empezar a mirar como
hacer explain plan.
Asegurate que las consultas que haces en ningun caso tengan full scan
( por ahi lei que tenes que crear indices lo cual es correcto)
Tambien fijate dentro de dicho explain las cardinalidades de los ind
Ivan Perales M. escribió:
> Mi pregunta era si hacer tablas hijas es equivalente a tener tablas en
> diferentes schemas.
No.
> Yo veo mas viable reprogramar a tener tablas en diferentes schemas que
> tablas hijas.
Por supuesto, es decisión tuya, pero cada vez que he visto hacer este
tipo de cos
Ok muchas gracias por sus comentarios, y no vayan a pensar que es
terquedad, pero técnicamente nadie me ha respondido jeje.
Si yo creo la tabla cliente1.cajas y cliente2.cajas, tengo un millon de
registros en cada una, cuando consulte cliente1.cajas, buscará entre los 2
millones o solo entre el mi
Ivan Perales M. escribió:
> Si yo creo la tabla cliente1.cajas y cliente2.cajas, tengo un millon de
> registros en cada una, cuando consulte cliente1.cajas, buscará entre los 2
> millones o solo entre el millon de registros de esa tabla?
Sólo uno, pero el sistema tendrá además que hacer la corres
Vamos a suponer que dejo los indices adecuados para las consultas mas
comúnes en una sola tabla. Todo es perfección hasta que el usuario dice,
necesito poder filtrar por todas las columnas, que haces? agregas indices
en cada una? y si filtra por dos o tres columnas de cualquier combinacion,
como pr
Ivan Perales M. escribió:
> Vamos a suponer que dejo los indices adecuados para las consultas mas
> comúnes en una sola tabla. Todo es perfección hasta que el usuario dice,
> necesito poder filtrar por todas las columnas, que haces? agregas indices
> en cada una?
No. Cuando eso pasa simplemente d
Bueno, ese no necesariamente lo entiendo como a veces sí y a veces no,
supongo va a depender de los casos de uso que vaya a tener el sistema.
Y si no es mucho abusar, en cuantos registros buscaría postgres si se hace
la sig consulta:
Tenemos las siguientes 3 tablas, cliente, material (que contiene
Disculpen me equivoque, la consulta es así:
select count(e.*) from cajas e
left join material m on m.id = e.material_id
where m.cliente_id = 10
2016-04-19 17:23 GMT-05:00 Ivan Perales M. :
> Bueno, ese no necesariamente lo entiendo como a veces sí y a veces no,
> supongo va a depender de los cas
18 matches
Mail list logo
