Cada vez q troyer coge vacaciones las acciones de donuts caen en picado
(no tiene dinero para comprarse donuts en casa)
#32580 mismamente una inserción como dices, tendrá pks, fgs, índices únicos, y para que haya seguridad, consistencia y concurencia se tiene que hacer en transacción. Vamos, hacer las cosas bien para que haya robustez. Así están las cosas, hechas mal, que después te piden robustez pero la bbdd que hay que migrar de la app origen te lo impide, y los clientes lloran y después a ver qué haces, te metes el palo por el culo.
Y te lo digo por experiencia, tenemos que migrar una app y una de las tablas viene con +500k registros y más del 30% de los registros vienen inconsistentes, con campos repetidos como el cif/nif y sin pks ni relaciones o campos metidos en un mismo campo, para supuestamente una app robusta :/. A ver qué haces.
por eso digo que el ejercicio ese que está haciendo, se lo están enseñando mal. Yo nada más entrar a ese nivel directamente a hacerlo con JDBC o Hibernate y que empiecen a trabajar los insert/update/delete con commit y rollback.
#32585 Comprendo, me has metido ganas ahora de empezar con Hibernate, conociendo al profesor me da que va a mostrar alguna forma de hacer la conexión a bd a pelo y luego nos enseñará lo "fácil" que es como Hibernate y tal.
Insertar 1M de articulos de una transaccion xdddddddddd
Vaya tela con alguna gente lol
Te falla en el ultimo y a tomar por culo
#32585 Pero si está haciendo una inserción de productos simples, no hay más, no va a tener fgs. Simplemente intenta insertar que falla -> a la tabla de fallos. Una única operación en ddbb ya es de por si una transacción implícita, no tiene que hacer más mierdas. Y de todas formas, no estamos desviando del tema que es el abuso de las excepciones. Y más aún, esto es FEDA.
Ontopic: suck JS, FP noobs, >1.4k
Pues si, un millon y si falla uno rollback... igual ese uno es una clave foránea de la que tiran el resto de registros... mola tener un millon de registros pensando que están "sanos" y resulta que cuando quieres tirar consulta peta por todos lados por que falta la referencia de turno.
Se nota que no lleváis software contable.... xDDD
#32595 Si es una foreign key de la que tiran el resto de registros no te va a dejar insertar el primer registro ya que te falta la FK lmao
Mucho software contable pero de base datos poquito eh
#32599 Creo que tu estas presuponiendo cosas al igual que yo... ¿Porque tiene que empezar la cosas con una base de datos vacia?
Otro ejemplo:
Tengo una factura a la que le quiero cambiar el precio de tres artículos... de las tres escrituras una falla, por asegurar la integridad de los datos lo hago en una transacción y si peta algo tiro de rollback. Muestro al usuario lo que ha petado, el usuario hace lo que tiene que hacer y vuelve a intentarlo.
Si tirase de trasacciones y rollback, otro usuario que editase la misma factura vería cambios "a medias" irreales con la verdadera situación de la factura... y empezaría la fiesta.
Nen que me da igual como lo digas, que NO contemplo meter datos a una base de datos relacional que no esten protegidos por FK. Me da igual como me lo quieras explicar, me da igual el estado de la base de datos. Si me dan una base de datos que no es consistente lo primero que voy a decirles es que con eso no se puede trabajar y que lo primero que hay que hacer es arreglar lo que hay antes de meterle mas mierda (y esto ya lo he hecho).
Lo mires por donde lo mires es una absurdez hacer una transaccion con 1M de inserts, es simplemente absurdo que se te joda uno y tengas que volver al principio. Es como si vas a barcelona desde cadiz y si pinchas una rueda a 50 kilometros tienes que volver a salir desde cadiz.
Tengo una factura a la que le quiero cambiar el precio de tres artículos...
Ahora me comparas 1M de inserts con 3 updates? kek
¿En serio estamos discutiendo si es correcto meter un millón de "filas" en una misma transacción? xD
#32601 es mejor abrir la factura y no ver ningún producto asociado. Qué ejemplo más malo has puesto.
Ya dejando de lado el tema de las inserciones (que a nada que hayáis gestionado alguna DB medio decente sabréis que lo que se está discutiendo es una estupidez), de qué sirve tener una FK con valores nulos? Para una auditoría quizás? Porque en la práctica es una tontería.
#32602 Si tengo el caso especial de tener que actualizar 1M de registros y solo peta uno... si, tienes razón... daría la transacción por buena y editaría ese registro "a mano".
Si tengo una factura con un millón de artículos y el usuario edita la factura para cambiar el precio de un millón de esos precios (ya que estamos en casos hipotéticos me imagino a un tipo con paciencia infinita) y de esas peta una escritura, tiro de rollback como manda el señor... quien no me dice a mi que no está otro usuario editando la misma factura y por culpa de usar la estrategia "hasta donde entre!" en el tiempo que el usuarioA tarda en corregir el único fallo no está el usuarioB haciendo uso de ese registro 'desfasado'? Y créeme cuando te digo que confiar en la rapidez del usuario es algo muy muy muy endeble... la memoria falla.. la pereza... el pensé que lo hice pero no se hizo... etc.. etc..
#32605 un ejemplo de eso, es los artículos que puedes agregar a un albarán que de repente vayas a hacer un insert y que no quede stock de uno de los artículos porque alguien fue más rápido y vacío el stock. No se le puedes dejar insertar un albarán con una ristra de artículos y decirle al final; eh, que este último artículo no te lo voy a insertar porque no queda en stock. Te jodes y haces otro albarán porque además, no se puede editar el contenido de un albarán dado de alta porque otro usuario podría estar gestionando la entrega de ese albarán.
y ojo, el albarán puede tener más de 500k artículos si le saliese de los huevos xd, pero no puedes insertar y los que fallen a tomar por culo y darle de alta el albarán y que después se ponga a toquetear el contenido, porque ese posible albarán puede ser un pedido y nada más tramitarlo se esté gestionando en otro lado haciendo que no haya consistencia.
3 ficheros, uno tiene datos de propietarios, otro datos de vehículos y otro la relación entre ellas.
Meto en spoiler, que me he pasado con las fotitas.
#32609 Mi idea para recoger los datos de los ficheros es recorrer el fichero con la relación, en cada linea mando a buscar e instancio el Propietario o el Vehiculo, esa información guardarla en un Arraylist<Propietario_Vehiculo>, luego mandar ese ArrayList a la clase Write para que los escriba al fichero.
Pensando se me ocurre otra opcion, en la clase Reader, cada vez que leo 1 propietario y 1 vehículo,llamar a Writer y escribirlos al fichero directamente, haciéndolo así no me haría falta ni las clases Propietario y Vehiculo siquiera.
Edit: Creo que si las necesitaría, al menos con la forma que conozco para hacer esto.
