Feda /dev/ - No Javascript allowed | Página 233

Markitos_182 #6961 Jun '20

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

1

B

[Borrado] #6962 Jun '20

.

isvidal #6963 Jun '20

#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 #6964 Jun '20 :psyduck:

#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 #6965 Jun '20

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 #6966 Jun '20

#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 #6967 Jun '20

mediante un trigger y nunca mediante software

klk

1

desu #6968 Jun '20

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 #6969 Jun '20

2 1 respuesta

wdaoajw #6970 Jun '20

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

desu #6971 Jun '20

#6969

1 1 respuesta

MTX_Anubis #6972 Jun '20 :psyduck:

#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 #6973 Jun '20

#6971

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

babri #6974 Jun '20

#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 #6975 Jun '20

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

2 respuestas

Lecherito #6976 Jun '20 A toda leche

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

_Rpv #6977 Jun '20

#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 #6978 Jun '20 Penitente

Titulitis la llaman.

Fyn4r #6979 Jun '20 Inocente

Otra vez esto no xd

1

pineda #6980 Jun '20

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

1 respuesta

neoline #6981 Jun '20

#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 #6982 Jun '20

pelea pelea!!

_Rpv #6983 Jun '20

#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 #6984 Jun '20

#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 #6985 Jun '20

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

1 respuesta

HeXaN #6986 Jun '20

Reeeeeeeeeeeee.

3

Fyn4r #6987 Jun '20 Inocente

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 #6988 Jun '20

#6985 y el tamaño del pene cuando?

1 respuesta

Wei-Yu #6989 Jun '20

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

afhn #6990 Jun '20 Guardia Imperial

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?

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales