Francisco, Creo que estamos en esta lista para ayudarnos mutuamente, y orientarnos de cómo resolver algunos problemas comunes que tenemos principalmente con postgresql, dependiendo de la relevancia del problema y el tiempo que tengamos podremos discutir mas/menos ampliamente del tema.
Lo que no me parece es el modo en que lo hacemos, y principalmente no comparto tu forma de regañar a las personas, y pienso que podría espantar a algunas personas de esta lista. No cuestiono la forma de ser de cada uno y sus particularidades!, la experiencia me ha enseñado a extraer lo positivo y valioso de las conversaciones por muy negras que se vean. Ahora, dependiendo de la persona que consulte, podrá analizar en su mérito si el código enviado, si le sirve o no, al igual que las extensas explicaciones, dudas e hipótesis planteadas por tí. Ambos métodos podrían confundir a personas mas novatas, código “complejo” o texto extenso!. No les parece raro q habiendo tanto hispano parlante llegue con suerte un par de correos semanales a esta lista?, vs otras listas de postgres que tienen decenas de interacciones diarias?. Los invito a revisar esto y a tratarnos con mejores forma, quizás aquí está la clave. saludos > El 15-05-2019, a las 06:01, Francisco Olarte <fola...@peoplecall.com> > escribió: > > Eduardo: > > On Tue, May 14, 2019 at 8:20 PM Eduardo Arenas <edo...@gmail.com> wrote: >> Ahí va el experimento con 1 millón de registros, y comprobación con una >> windows función de que el procedimiento entrega igual cantidad de días de la >> semana aprox en la muestra. > > Nadie duda que puedas hacer un query que genere un numero aleatorio, y > una cantidad igual de dias de la semana, pero ...pero..... > >> drop table if exists random_semana; >> create temp table random_semana as >> with consulta as ( >> select generate_series(1,1000000) as q >> ) >> select q,trunc(ran) as ran >> from >> ( >> select * >> ,random()*7+1 as ran >> from consulta >> ) as a; > > Ese query parece hecho a posta pa confundir a alguien en una pregunta > de examen, ¿ porque un CTE y un select anidado en lugar de dos del > mismo tipo ? > Eso parece generar sin mas una lista numerada de 1 millon de numeros > aleatorios de 1 a 7... > >> select *,count(*) over (partition by ran) from random_semana order by 1; > > Y esto parece que los cuenta. No se que tiene que ver esto con el > sacar una muestra aleatoria con unas caracteristicas dadas. Si lo que > pretende es probar que el generador de aleatorios no es > espectacularmente malo, parece correcto. Ahora bien, si cambias el > limite de un millon a siete, por aquello de que sea divisible por 7, > repites el experimento 100 veces, p.e., y en todas te salen 1 millon > de cada clase yo me preocuparia ( por hacer experimentos estadisticos > que tampoco solucionan el problema pero son algo mas truculentos ). > >> PS… Hay cosas que se puede resolver discutiendo, y otras q se puede resolver >> haciendo el experimento… esta es una de ellas. La documentación de un >> sistema es el código funcionando, que es lo que hace funcionar al sistemas, >> el resto es música!. > > Aqui no se discutia mucho, pero bueno. Dejando aparte que no se que > intenta probar ese query, hay cosas que hay que mirar antes. Una > solucion probabilistica puede ser suficientemente buena para lo que se > quiere, pero hay que tener aprobacion de que lo es. Una seleccion > aleatoria de muestras funcionando un millon de veces no te garantiza > que funcione a la siguiente, lo sabes de sobra. Es como el tipico > problema de "quiero mandar el user ID pero que no se vea que viene de > un serial, voy a mandar el <insert favorite hash function>". Eso puede > colisionar ( si no demuestras primero que tu funcion de hash no tiene > colisiones en el dominio de los user id ), por lo que hay que usar una > funcion de encriptacion. Puedes generar trillones de user ids y no > tener colisiones, pero necesitas una funcion invertible para > garantizar que no las tienes. O puedes decirle al jefe que vas a usar > un codigo mas simple y barato, que lo has probado unas cuantos > millones de veces, y que la probabilidad de colision es tan baja que > no justifica el coste de hacer uno correcto. > > Francisco Olarte.
