Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Markitos_182

Mejor campo string y que el valor por defecto sea 'lol no'

1
B

.

isvidal

#6960 El problema es tambien filosofico.

No es el mismo momento el que se instacia el objeto y se guarda su valor en una posición de la memoria, que el momento en el que se setea su propiedad de created_at, por tanto, se puede considerar, que, sujetas a las circunstancias contempladas, el objeto SI HA sido actualizado en el mismo momento de su creacion y por ende, updated_at seteado tiene todo el sentido del mundo.

MTX_Anubis

#6960 Yano voy a entrar en el debate de si se actualiza o no (que puedes tener parte de razón aunque para mi insertar un registro es actualizarlo también) si no te convence el nombre, cambialo a saved_at y ya está. O tampoco lo estás guardando cuando lo creas?

Es que hay que ser pragmático, si ordernas por updated_at y es como tu dices ya te toca trabajar nulls y meter el created_at por el medio (y venga fiesta como tengas que entrar a cruzar tablas y registros y sus coalesces). Y una vez sacado de la BBDD lo mismo, si quieres hacer comparaciones ya te toca estar trabajando con varios campos a la vez por querer diferenciar los estados de actualización y creación. No sé qué es más sencillo para ti vamos.

1 1 respuesta
Ranthas

Teniendo en cuenta que

  • El campo create_at debe informarse mediante un trigger a INSERT y nunca mediante software

  • El campo update_at debe informarse mediante un trigger a UPDATE y nunca mediante software

Pues todo dicho

eXtreM3

#6964 no es justo al revés? Si quiero ordenar por updated_at me traigo los distintos de null y ya tengo únicamente las tuplas que 100% han sido actualizadas.

De la otra forma, si por lo que sea un registro se ha actualizado en el mismo segundo que se ha creado, ya es imposible que sepas si se ha actualizado alguna vez.

Es que para eso saco el updated_at de esa tabla y me hago otra que sea para guardar el historial de cambios, y ya todo lo que haya ahí será update del id al que hace referencia.

2 respuestas
Wei-Yu

mediante un trigger y nunca mediante software

klk

1
D

Dos maneras de plantear el problema, segun el dominio vs segun los casos de usos de la aplicacion.

Por el lado del dominio imaginemos que hablamos de vehiculos, los vehiculos no tienen un campo creado / modificado. Los vehiculos tienen los campos de informacion de la entidad. Tanto el creado como el modificado son meta datos. Si los campos de las entidades dependiesen si ha sido creado o modificado, por ejemplo si es una tienda tener un listado de reparaciones, entonces tendria sentido separar completamente las entidades en Vehiculo y VehiculoModificado.

Desde el punto de vista de los casos de usos me pregunto que operaciones seran las mas frequentes y que informacion podre cachear en ram sin tener un sobre coste. Aqui esta claro que no vamos a tener 2 tablas si solo tenemos esos dos metadatos y si no requerimos una cache podemos tener el metadato createad_at atribuido a la entidad del vehiculo (aunque a nivel de dominio no sea correcto) y por otro lado tener el historial del modificado por separado. Esta manera permitiria consultar solo los modificados de manera facil si por ejemplo queremos vehiculos en un rango de tiempo concreto(esto es un caso de uso).

Dicho esto a nivel de codigo de programacion de la logica de tu proyecto trabajar siempre en dominio (claridad, entendimiento de codigo), a nivel de base de datos siempre trabajar priorizando los casos de uso (rendimiento, eficiencia). Obviamente no tengo ni puta idea y no he hecho una base de datos en mi vida, pero esto, se daba por entendido.

Wei-Yu

2 1 respuesta
wdaoajw

#6956 porque a la larga te va a dar problemas, si no a ti, a otro. Referencias a null que petardean por ejemplo.

D

#6969

1 1 respuesta
MTX_Anubis

#6966 no sé que casos te has encontrado donde quieres que se ordenen mediante el updated_at y no tengas que ordenar los de nueva creación (o al revés). Yo de momento creo que ninguno. Lo normal es ordenar por fecha de última modificación y ahí lo normal es incluir la de creación y cuantos mas NULLs evites mejor porque cada BBDD los trata de una forma diferente, el resto me parece buscarle 3 pies al gato.

Sobre lo que dices las BBDD también guardan milisegundos y nunca van a ser iguales pero vamos, si tu caso de uso requiere separar de esa forma la creación y actualización de registros y además tus timestamps no guardan milisegundos pues es obvio que así no puedes hacerlo y tendrás que hacerlo como dices pero según lo planteas para que sea siempre así estás generalizando un edge case porque como te digo, no es lo normal xD

Y lo que dices de añadir otra tabla, si no vas a tener un registro histórico de updates, es una tontería que solo añade, nuevamente, más complejidad.

Zoko

#6971

Como manejas el inspector de elementos y el HTML socio, se nota el toque de leetcode.

babri

#6966 si updated_at = created_at es que nunca se actualizó.

además te invito a que hagas un sistema de auditoria para saber que user es que ha editado que, para que así sepas quien y cuando lo ha editado.

neoline

Oye, que pasa!

- Debes odiar a la gente que no haya hecho la carrera y sobre todo, sean de FP

Vengo a defender a la gente de FP, he trabajado en más de 6 equipos y nunca me he sentido por debajo de nadie de carrera.
También me parece que si te vas a dedicar solo a dev, en la carrera se da mucha matería que no necesitas (al menos directamente).

FP :muscle:

2 respuestas
Lecherito

#6975 pues siento darte con la realidad pero los de fp apenas valen para nada

_Rpv

#6975 Soy de fp y te aseguro que somos inferiores a los de carrera.
En la fp no te enseñan ni a calcular el coste de algoritmos, ni patrones...
Te enseñan a programar en dos/tres lenguajes y vas que chutas.

1 respuesta
Dry-Prime

Titulitis la llaman.

Fyn4r

Otra vez esto no xd

1
pineda

hay 2 tipos de programadores: los que quiero en mi equipo y los de FP

1 respuesta
neoline

#6977 A mi me enseñaron C y C++ que creo que es una buena base.
Lo que juega FP es aprender trabajando. Al fin y al cabo puedes empezar antes en el mundo laboral y si pones de tu parte cambia mucho la cosa. Tengo amigos que cuando acabaron Informática ya llevaba yo 3 años trabajando con object pascal.

#6980 xD

1 respuesta
babri

pelea pelea!!

_Rpv

#6981 Te doy la mitad de razón. Puedes aprender trabajando, sí. Pero trabajando no vas a aprender si es más rentable hacer una busqueda en una lista o en un array, y no te digo más tipos de estructuras de datos porque no se enseñan en la fp.

1 respuesta
neoline

#6983 Con años de experiencia creo que si.
Depende bastante de en lo que acabes trabajando, claro, incluso dónde y con qué equipo.
Eso lo cambia todo.

Después el tema laboral y cobrar menos etc... desde hace muchos años en mi contrato pone "Software Engineer" y así me considero, sin complejos.

Wei-Yu

bueno después de esta toca hablar de sueldos no?

1 respuesta
HeXaN

Reeeeeeeeeeeee.

3
Fyn4r

Voy a zanjar esto, va ( @jastro , ponlo en la cabecera o algo):

  • Gente que cree que sabe programar pero no tiene ni puta idea: FP, teleco, matemáticas, física
  • Gente que cree que sabe programar, no tiene ni puta idea pero parte de una base decente: Informática
  • Gente que sabe programar: Cualquiera que se lo proponga, si esto se basa en saber adaptar lo que buscas en google

FIN

4 2 respuestas
neoline

#6985 y el tamaño del pene cuando?

1 respuesta
Wei-Yu

no, luego va llorar de mierdas de tu curro y perdona que te diga pero soy un crack en eso

afhn

que miedo

SQL> drop pluggable database ****** including datafiles;

Base de datos de conexi¾n borrada.

PD: alguien ha usado hazelcast alguna vez o lo conoce?