Respuestas:
Debe describir el propósito de la columna y no necesariamente el tipo de datos. Puede incluir fecha / hora / marca de tiempo en el nombre, pero también debe incluir el significado. Por ejemplo
Agregar fecha / hora / marca de tiempo y tal al final es particularmente útil cuando la ausencia de la adición entraría en conflicto con otra columna. Por ejemplo, una tabla puede necesitar un Status y un StatusTime.
¿Qué tal xyz_atun timestampay xyz_onpara un datecampo, por ejemplo, start_ato start_on?
Normalmente evitaría incluir el tipo de datos en el nombre del campo, mucho mejor si puede inferir lo que necesita saber sobre el tipo a partir del nombre de cualquier campo ( descriptiones poco probable que un campo llamado sea un integer), pero poder saber La diferencia entre ay timestampa datemenudo es útil.
Yo suelo:
updated_atpodría ser cualquiera. Pero creo que la respuesta es, como siempre con los nombres, usar el nombre más conciso que elimine toda ambigüedad realista. Es decir, si en un contexto particular existe la posibilidad de una cierta confusión,
Miré tu perfil y dice que trabajas con SQL Server y en el tipo de datos TIMESTAMP de SQL Server no tiene nada que ver con la fecha o la hora y se usa para el tipo de versión que estampa las filas. Esto es muy útil para identificar qué filas se han modificado desde un punto de tiempo dado.
Si usa TIMESTAMP, entonces no tiene que especificar un nombre de columna y SQL Server creará una columna "TimeStamp" para usted. Pero se recomienda utilizar el tipo de datos "ROWVERSION" y en este caso debe especificar el nombre de la columna.
¿Cuál es el mejor nombre para una columna como esta? Depende, y usaría algo como VersionStamp, RV, etc. Lo que considero importante NO es cómo lo nombras, sino que lo usas de manera consistente en todos los ámbitos.
HTH
Ref: http://msdn.microsoft.com/en-us/library/ms182776(v=sql.90).aspx
Descubrí que usar nombres de columna como create_time, update_timey expire_timeconduce a una mejor legibilidad cuando se trata de nombres de métodos y especificaciones (RSpec).
Prefiero usar un prefijo de DT para sellos de fecha. Por ejemplo: DTOpened, DTClosed, DTLastAccessed. Esto me permite enumerar todos los DTxxxx para obtener una referencia rápida de todos los sellos de fecha en una tabla determinada.
Trabajo para Texas Instruments, y en sus sistemas usan xxxx_ dttm
Prefiero usar convenciones que ya existen.
Los lenguajes de programación y Unix tienen una convención ampliamente aceptada mtimepara el tiempo de modificación
Por tiempo de creación,
btimecrtimeotime(no preguntar, adivinar "origen").Entonces, para mí, elijo mtimey crtimepara los metadatos.
Para los datos proporcionados por el usuario, voy con lo que representa el campo. Si es un cumpleaños, solo digo user_birthday.
En cuanto a la precisión, para algunos parece colgarlos con demasiada precisión. Puede almacenarlo birthdatecomo una marca de tiempo (después de todo, técnicamente nació en un momento del día), pero la especificación SQL tiene conversiones de mayor precisión a menor precisión, por lo que si está utilizando una base de datos decente, esto no debería ser un problema . En su propia aplicación, siempre puede truncar cuando sea necesario. Es decir, nunca iría birthday_date.
Usaría un prefijo significativo y _TSMP como sufijo, por ejemplo, CREATION_TSMP o LAST_UPDATE_TSMP
Como sugiere @Evan Carroll, siga los estándares existentes a menos que tenga una buena razón para romper el patrón.
Si esto es algo nuevo, puede seguir cualquier respuesta que más le convenga.
Uso * _on y * _by porque me ayuda a mantenerlo constante para cuándo y quién de la fila:
- created_on & created_by
- updated_on & updated_by
- deleted_on & deleted_by -- soft delete
- approved_on & approved_by