angelino pero los billetes que hayan metido que han sido con nick o como anonimos???
podrian borrar todos los billetes metidos por ese nick o todos los anonimos de esta noche y dejar los que hayan metido otras personas, no entiendo que quiten el billete entero en vez de la introduccion
suerte y a ver si lo arreglan saludos
angel
HITS ESPAÑOLES
Moderator: N0W1K
Buenas, acabo de llegar a casa y ahora veo que habeis tenido un problema.
A parte de Angelino alguien más ha visto modificados sus hits??? Si es así mandadme un PM especificando cuales, mañana intentaré hablar con los jefes a ver que se puede hacer.
Angelino, por favor, ten paciencia, sabes que haré encantada todas las gestiones posibles para que todo se arregle.
A parte de Angelino alguien más ha visto modificados sus hits??? Si es así mandadme un PM especificando cuales, mañana intentaré hablar con los jefes a ver que se puede hacer.
Angelino, por favor, ten paciencia, sabes que haré encantada todas las gestiones posibles para que todo se arregle.
Ayer haciendo el ranking pude comprobar que sólo ese hit parece haber estado afectado por el tramposo. Eso, claro está, de los usuarios del Top 50 español (europeos sí ha habido más). También puede hacer afectado a algún hit de alguien fuera del Top 50, pero no parece algo muy 'masivo'.
Ya sé que tú (y no solamente tú) estarás encantada de hacer lo que sea por recuperar la situación anterior, pero me temo que no es posible.
Aunque nunca estuve afectado anteriormente, si no recuerdo mal hace tiempo hubo un problema muy similar y no se pudo arreglar. Creí entender que la base de datos contiene billetes y no hits. Cuando se reintroduce un billete por otra persona (y en un día diferente) se 'marca' ese mismo billete, pero no se crea otro registro.
Por tanto, pueden desmoderar el triple hit (no sería correcto, pues es un falso triple hit, y por tanto no han de hacer esto) pero nada más. Pueden borrar el registro, es decir, el billete, pero entonces c.moreu y yo perderemos el billete (encima!) y no recuperaremos el hit. En fin, que me temo es MISION IMPOSIBLE.
Puedes preguntarlo a los 'supertacañones'
pero me temo que la respuesta será similar a lo que digo. Cosa de la experiencia.... 
aunque hojalá esté equivocado.
En fin, echo unas lagrimitas finales por mi ex-hit
(el segundo que más me gustaba, tras el internacional) y a seguir viviendo.
Ya sé que tú (y no solamente tú) estarás encantada de hacer lo que sea por recuperar la situación anterior, pero me temo que no es posible.
Aunque nunca estuve afectado anteriormente, si no recuerdo mal hace tiempo hubo un problema muy similar y no se pudo arreglar. Creí entender que la base de datos contiene billetes y no hits. Cuando se reintroduce un billete por otra persona (y en un día diferente) se 'marca' ese mismo billete, pero no se crea otro registro.
Por tanto, pueden desmoderar el triple hit (no sería correcto, pues es un falso triple hit, y por tanto no han de hacer esto) pero nada más. Pueden borrar el registro, es decir, el billete, pero entonces c.moreu y yo perderemos el billete (encima!) y no recuperaremos el hit. En fin, que me temo es MISION IMPOSIBLE.
Puedes preguntarlo a los 'supertacañones'
pero me temo que la respuesta será similar a lo que digo. Cosa de la experiencia.... aunque hojalá esté equivocado.En fin, echo unas lagrimitas finales por mi ex-hit
(el segundo que más me gustaba, tras el internacional) y a seguir viviendo.-
Andres_age
- Euro-Expert in Training
- Posts: 396
- Joined: Wed Mar 16, 2005 10:14 pm
- Location: Palma de Mallorca - 4047 notes
Me parece muy extraño que no se pueda "deshacer" este hit. Aún si solo se guardan los billetes y no los hits, no veo forma de que la última información no se pueda borrar, aunque sea a bajo nivel con SQl directamente. Sabeis cual es su estructura, su modelo relacional o MER? He pensado varias veces como implementar un "EBT" con una base de datos (para practicar MER, incluso llegué a hacerlo en Interbase 
), y en todas este "error" se podría deshacer.
), y en todas este "error" se podría deshacer.Tus conocimientos de bases de datos relacionales veo que son amplios, profundos y prácticos. Yo no sé nada o casi nada de SQL ni de esos modelos, pero sólo repito lo que dentro de mi ignorancia creí entender alguna otra vez. 
A lo mejor simplemente, no resulta práctico llevarlo a cabo, o quizá,...quizá sí haya un rayo de esperanza 
A lo mejor simplemente, no resulta práctico llevarlo a cabo, o quizá,...quizá sí haya un rayo de esperanza
-
Andres_age
- Euro-Expert in Training
- Posts: 396
- Joined: Wed Mar 16, 2005 10:14 pm
- Location: Palma de Mallorca - 4047 notes
No se como está implementada la base de datos de EBT, ni cual es su diseño ni nada. Pero suponiendo que usa la típica base de datos relacional (es decir, nada de orientada a objetos ni cosas raras ), creo que es dificil por no decir imposible hacer un diseño que no permita borrar estos hits.
Veamos, las posibilidades que hay (a muy grandes rasgos)
1) Hacer dos tablas, una de usuarios y otra de billetes.
La de billetes tendrá unos atributos que serán los usuarios que lo han metido
Por ejemplo
usuario(nombre,poblacion,codigo postal, etc)
billete(codigo corto, codigo largo, fecha1, usuario1, cp1, fecha2, usuario2, cp2, etc etc)
Entonces usuario será el nombre del usuario que lo ha metido por primera vez, fecha1 será la fecha cuando se insertó por primera vez, etc. Igual para cp2, cp3, cp4, etc. Si solo se ha metido una vez, los atributos cp2, fecha2, etc serán nulos.
Vale, este diseño tiene varios problemas. Uno, hay un límite para el limite de usuarios por billete. Si hemos hecho
billete(codigo corto, codigo largo, fecha1, usuario1, cp1, fecha2, usuario2, cp2)
y un tercer usuario intenta meter el billete, entonces ya no puede. Esto no pasa en EBT (hay hits de 3 personas o más), pero si lo han hecho así estaría limitado a por ejemplo 10 o el número que sea.
Es muy poco práctico y ni siquiera sigue la primera forma normal. Vamos, que hablando claramente es una chapuza.
2) Lo mismo que antes, dos tablas pero ahora en la tabla de usuarios guardamos los billetes
billete(codigo corto, codigo largo)
usuario(nombre,poblacion,billete1,cp1,billete2,cp2,etc)
Esta opción la menciono para descartar ideas, pero es totalmente inviable. ans tendría una tupla con 350.000 atributos (dos por billete metido) lo mismo que antes, lo que pasa es que en vez de haber un limite de usuarios por billete, el limite está en billetes por usuario.
3) La opción "típica" y creo que la que han usado (o variantes, o cosas más complejas, pero en general siguiendo este esquema).
Han hecho una relación N-N y se forman 3 tablas
billete(codigo corto, codigo largo)
usuario(nombre,poblacion, etc)
inserción (billete_insertado, usuario_insertador,fecha,cp)
Entonces cada vez que un usuario inserte un billete se crea una nueva tupla en la tabla "insercion" con los datos pertinentes:fecha, codigo postal, billete, usuario que lo ha metido, etc. De esta forma los billetes se pueden insertar sin limites, igual que los usuarios. Cada nueva inserción, sería una nueva tupla.
Por ejemplo
insercion
(x11111111,angelino,1-6-05,28080)
(v11133331,andres_age,2-6-05,27000)
(x11111111,pepe,10-6-05,07050)
Entonces los hits serían las tuplas con el mismo billete, es decir la primera y tercera en este ejemplo.
Desventajas de este metodo? Es muy lento. Pero que muy lento. Habría que buscar todas las repeticiones de cada billete de entre millones de tuplas. Si no se usa indexación o arboles b+ o algo para agilizar las consultas, hallar la lista de billetes de un usuario es algo brutal. Sin embargo es la solución más flexible, y por eso creo que es así como está implementada la base de datos de EBT (pero repito, se apoyará en pre-indexación o algo, porque sino esto es LENTIIIIISIMO)
Supongamos que tenemos
(x11111111,angelino,1-6-05,28080)
(x11111111,pepe,10-6-05,07050)
Y viene un perraco y hace
(x11111111,cabron,11-6-05,77777)
Entonces tenemos un hit triple y falso.
Entonces, como solucionar este caso?
Pues simplemente borrando esta última tupla. Como? Lo más fácil sería coger todas las inserciones del usuario cabron y borrarlas una por una (se puede hacer con una sola linea SQL).
Así quedaría como antes.
Problemas que puede haber? Que para agilizar la base de datos, se haya hecho una tabla con datos duplicados. Por ejemplo una tabla que guarde los hits (que parece que no hay) o cualquier otra cosa. Entonces sería muy peliagudo y habría que ir con pies de plomo, ya que si no borramos todos los datos, puede quedar descolgado y fallar.
Mientras mejor diseñada esté la base de datos, mejor y más fácil solucionar este problema. Pero si no está normalizada, si hay duplicación de datos para mejorar la rapidez, etc entonces más dificil es arreglar esto.
Por eso habría que saber COMO está hecha la base de datos de EBT, y si se arregla tendría que ser alguien a mano, que sepa perfectamente como esta hecha la base de datos, y con pies de plomo tocar dato por dato y borrar lo que haga falta. No es inviable, al menos no creo (quiero pensar que la base de datos de EBT es solida y está bien hecha), pero quizás los "jefes" no tengan tiempo de ocuparse de esto y de toquetear demasiado la base de datos (que tampoco es un gran problema, para algo están los backups, si hay algun problema se restaura la copia de seguridad y listos) (además, bastaría hacer un DELETE de un SELECT de los billetes metidos por ese usuario, cosa que se hace en una linea, no hace falta tampoco mirar caso por caso manualmente, si todos siguen el mismo patron se eliminan todos de golpe, sean 10 o 10000).
Ya se que me ha quedado un post rollo y muy técnico, pero creo que al que le interese saber como puede funcionar una base de datos por dentro, y como se podría arreglar este embrollo, le puede interesar...
Si se puede hablar con los capos, a ver si pueden hacer algo, mejor que mejor. Poder, estoy casi seguro que se puede. El problema es el tiempo que tardaría y principalmente del tiempo que disponen los 3 webmasters...
), creo que es dificil por no decir imposible hacer un diseño que no permita borrar estos hits.Veamos, las posibilidades que hay (a muy grandes rasgos)
1) Hacer dos tablas, una de usuarios y otra de billetes.
La de billetes tendrá unos atributos que serán los usuarios que lo han metido
Por ejemplo
usuario(nombre,poblacion,codigo postal, etc)
billete(codigo corto, codigo largo, fecha1, usuario1, cp1, fecha2, usuario2, cp2, etc etc)
Entonces usuario será el nombre del usuario que lo ha metido por primera vez, fecha1 será la fecha cuando se insertó por primera vez, etc. Igual para cp2, cp3, cp4, etc. Si solo se ha metido una vez, los atributos cp2, fecha2, etc serán nulos.
Vale, este diseño tiene varios problemas. Uno, hay un límite para el limite de usuarios por billete. Si hemos hecho
billete(codigo corto, codigo largo, fecha1, usuario1, cp1, fecha2, usuario2, cp2)
y un tercer usuario intenta meter el billete, entonces ya no puede. Esto no pasa en EBT (hay hits de 3 personas o más), pero si lo han hecho así estaría limitado a por ejemplo 10 o el número que sea.
Es muy poco práctico y ni siquiera sigue la primera forma normal. Vamos, que hablando claramente es una chapuza.
2) Lo mismo que antes, dos tablas pero ahora en la tabla de usuarios guardamos los billetes
billete(codigo corto, codigo largo)
usuario(nombre,poblacion,billete1,cp1,billete2,cp2,etc)
Esta opción la menciono para descartar ideas, pero es totalmente inviable. ans tendría una tupla con 350.000 atributos (dos por billete metido)
lo mismo que antes, lo que pasa es que en vez de haber un limite de usuarios por billete, el limite está en billetes por usuario.3) La opción "típica" y creo que la que han usado (o variantes, o cosas más complejas, pero en general siguiendo este esquema).
Han hecho una relación N-N y se forman 3 tablas
billete(codigo corto, codigo largo)
usuario(nombre,poblacion, etc)
inserción (billete_insertado, usuario_insertador,fecha,cp)
Entonces cada vez que un usuario inserte un billete se crea una nueva tupla en la tabla "insercion" con los datos pertinentes:fecha, codigo postal, billete, usuario que lo ha metido, etc. De esta forma los billetes se pueden insertar sin limites, igual que los usuarios. Cada nueva inserción, sería una nueva tupla.
Por ejemplo
insercion
(x11111111,angelino,1-6-05,28080)
(v11133331,andres_age,2-6-05,27000)
(x11111111,pepe,10-6-05,07050)
Entonces los hits serían las tuplas con el mismo billete, es decir la primera y tercera en este ejemplo.
Desventajas de este metodo? Es muy lento. Pero que muy lento. Habría que buscar todas las repeticiones de cada billete de entre millones de tuplas. Si no se usa indexación o arboles b+ o algo para agilizar las consultas, hallar la lista de billetes de un usuario es algo brutal. Sin embargo es la solución más flexible, y por eso creo que es así como está implementada la base de datos de EBT (pero repito, se apoyará en pre-indexación o algo, porque sino esto es LENTIIIIISIMO)
Supongamos que tenemos
(x11111111,angelino,1-6-05,28080)
(x11111111,pepe,10-6-05,07050)
Y viene un perraco y hace
(x11111111,cabron,11-6-05,77777)
Entonces tenemos un hit triple y falso.
Entonces, como solucionar este caso?
Pues simplemente borrando esta última tupla. Como? Lo más fácil sería coger todas las inserciones del usuario cabron y borrarlas una por una (se puede hacer con una sola linea SQL).
Así quedaría como antes.
Problemas que puede haber? Que para agilizar la base de datos, se haya hecho una tabla con datos duplicados. Por ejemplo una tabla que guarde los hits (que parece que no hay) o cualquier otra cosa. Entonces sería muy peliagudo y habría que ir con pies de plomo, ya que si no borramos todos los datos, puede quedar descolgado y fallar.
Mientras mejor diseñada esté la base de datos, mejor y más fácil solucionar este problema. Pero si no está normalizada, si hay duplicación de datos para mejorar la rapidez, etc entonces más dificil es arreglar esto.
Por eso habría que saber COMO está hecha la base de datos de EBT, y si se arregla tendría que ser alguien a mano, que sepa perfectamente como esta hecha la base de datos, y con pies de plomo tocar dato por dato y borrar lo que haga falta. No es inviable, al menos no creo (quiero pensar que la base de datos de EBT es solida y está bien hecha), pero quizás los "jefes" no tengan tiempo de ocuparse de esto y de toquetear demasiado la base de datos (que tampoco es un gran problema, para algo están los backups, si hay algun problema se restaura la copia de seguridad y listos) (además, bastaría hacer un DELETE de un SELECT de los billetes metidos por ese usuario, cosa que se hace en una linea, no hace falta tampoco mirar caso por caso manualmente, si todos siguen el mismo patron se eliminan todos de golpe, sean 10 o 10000).
Ya se que me ha quedado un post rollo y muy técnico, pero creo que al que le interese saber como puede funcionar una base de datos por dentro, y como se podría arreglar este embrollo, le puede interesar...
Si se puede hablar con los capos, a ver si pueden hacer algo, mejor que mejor. Poder, estoy casi seguro que se puede. El problema es el tiempo que tardaría y principalmente del tiempo que disponen los 3 webmasters...
Angelino
Anoche estuve un rato hablando con Avij y le pregunté qué pasaba con el triple hit que os afectaba a vosotros. Al final no pudimos terminar la conversación puesto que se tuvo que marchar. Esta noche seguiré hablando con él a ver qué se puede hacer
Ralf ha sido otro de los afectados por culpa de ese triple hit
Anoche estuve un rato hablando con Avij y le pregunté qué pasaba con el triple hit que os afectaba a vosotros. Al final no pudimos terminar la conversación puesto que se tuvo que marchar. Esta noche seguiré hablando con él a ver qué se puede hacer
Ralf ha sido otro de los afectados por culpa de ese triple hit
-
Spanier_20
- Euro-Master in Training
- Posts: 800
- Joined: Thu Apr 22, 2004 4:47 pm
- Location: Nürnberg - Germany
Y yo tambien soy un afectado.
Este hit le pasa como al de Angelino:
http://www.eurobilltracker.eu/index.php ... 8448a0f66d
Y estos no eran Hit pero hizieron un triple de el:
http://www.eurobilltracker.eu/index.php ... 8448a0f66d
En total tengo 16 Hits falsos. Y esto ha pasado a muchos usuarios alemanes tambien.
Esperemos que se arregle todo.
Os saludo
Este hit le pasa como al de Angelino:
http://www.eurobilltracker.eu/index.php ... 8448a0f66d
Y estos no eran Hit pero hizieron un triple de el:
http://www.eurobilltracker.eu/index.php ... 8448a0f66d
En total tengo 16 Hits falsos. Y esto ha pasado a muchos usuarios alemanes tambien.
Esperemos que se arregle todo.
Os saludo
-
Andres_age
- Euro-Expert in Training
- Posts: 396
- Joined: Wed Mar 16, 2005 10:14 pm
- Location: Palma de Mallorca - 4047 notes
Y los tios no paran. Este se acaba de hacer hará 5 minutos 
http://www.eurobilltracker.eu/index.php ... id=8396568
Al menos el billete no era un hit...
http://www.eurobilltracker.eu/index.php ... id=8396568
Al menos el billete no era un hit...
-
yonsek
- Euro-Expert
- Posts: 514
- Joined: Tue May 17, 2005 8:25 pm
- Location: El Puerto de Santa Maria
- Contact:
Y si   esta teniendo tantos hits, ¿por qué cuando pulsas en su nombre de usuario y te manda a su página aparecen 0 hits interesantes?
¿Es que a este usuario que parece que hace tantos hits, no le cuentan, o son todos moderados?
este es el link de su página de usuario:
http://www.eurobilltracker.eu/index.php ... 081fbd4527
¿Es que a este usuario que parece que hace tantos hits, no le cuentan, o son todos moderados?
este es el link de su página de usuario:
http://www.eurobilltracker.eu/index.php ... 081fbd4527
Yonsek, son moderados todos los hits del innombrable.
Tengo otro no interesante con el mismo elemento. Me ha 'hecho' un hit falso:
http://www.eurobilltracker.eu/index.php ... id=4866743
y nada menos un billete de 100 portugués!!, que debe ser el único que he visto jamás. En fin, en este caso, el hit está moderado y punto.
Pero se está pasando de la raya, y más si hay bastante gente afectada, que yo pensaba éramos menos.
Tengo otro no interesante con el mismo elemento. Me ha 'hecho' un hit falso:
http://www.eurobilltracker.eu/index.php ... id=4866743
y nada menos un billete de 100 portugués!!, que debe ser el único que he visto jamás. En fin, en este caso, el hit está moderado y punto.
Pero se está pasando de la raya, y más si hay bastante gente afectada, que yo pensaba éramos menos.
-
Spanier_20
- Euro-Master in Training
- Posts: 800
- Joined: Thu Apr 22, 2004 4:47 pm
- Location: Nürnberg - Germany
Hola a todos,
se comenta en el foro aleman que puede ser que los datos de los billetes los coja de otra paguina. Porque en una de las otras paguinas de registrar Billetes se ve el numero excepto
las ultimas tres cifras. Angelino tu debes ser el unico en Espana afectado.
Han llegado a esta conclusion porque nunca les a tocado a ans, bhoeyb, J.R.K., etc....
Pero si a joergb30, Angelino, Helge, Androl, Ernst, Ralf (Holanda) a mi, etc....
Vamos haber lo que pasa.
Os saludo
se comenta en el foro aleman que puede ser que los datos de los billetes los coja de otra paguina. Porque en una de las otras paguinas de registrar Billetes se ve el numero excepto
las ultimas tres cifras. Angelino tu debes ser el unico en Espana afectado.
Han llegado a esta conclusion porque nunca les a tocado a ans, bhoeyb, J.R.K., etc....
Pero si a joergb30, Angelino, Helge, Androl, Ernst, Ralf (Holanda) a mi, etc....
Vamos haber lo que pasa.
Os saludo
Acabo de ver un mensaje en esa misma línea en el foro de 'EBT Users'. Ciertamente observando los afectados, pues coincide con los que metemos los billetes en esa otra página (al menos)....Spanier_20 wrote: Porque en una de las otras paguinas de registrar Billetes se ve el numero excepto las ultimas tres cifras. Angelino tu debes ser el unico en Espana afectado.
¿Quizá además los que utilicemos XInsert para pasarlos de un lugar a otro???? En ese sistema se envían por correo los números enteros.
Lo digo porque parece ser que el 'amigo' no hace mil intentos por cada número, sino que parece que lo introduce A LA PRIMERA, y si es así ¿como adivina los tres últimos dígitos del número de serie?. También puede ser que esté equivocado y no haya entendido bien los mensajes en inglés que he visto.
-
Spanier_20
- Euro-Master in Training
- Posts: 800
- Joined: Thu Apr 22, 2004 4:47 pm
- Location: Nürnberg - Germany
Si lo has entendido bien, eso no lo se como averigua los ultimos tres numeros.Angelino wrote: Lo digo porque parece ser que el 'amigo' no hace mil intentos por cada número, sino que parece que lo introduce A LA PRIMERA, y si es así ¿como adivina los tres últimos dígitos del número de serie?. También puede ser que esté equivocado y no haya entendido bien los mensajes en inglés que he visto.
Pero casi siempre lo da a la primera....