php - estandares - eloquent laravel 5 español

Laravel: convenios de nomenclatura de bases de datos, tablas y columnas

Question

Estoy usando objetos de datos elocuentes de laravel para acceder a mis datos, ¿cuál es la mejor manera de nombrar mis tablas, columnas, claves externas / extranjeras, etc.?

Encontré, hay muchas convenciones de nombres por ahí. Me pregunto cuál se adapta mejor a los modelos elocuentes de Laravel.

Estoy pensando en seguir la convención de nombres:

1. Nombres de tablas singulares (por ejemplo: Publicar)
2. Nombres de columnas singulares (por ejemplo: userId - id de usuario en la tabla de publicaciones)
3. Camel case para múltiples palabras en nombres de tablas (ej: PostComment, PostReview, PostPhoto)
4. Camel Camel para múltiples palabras en nombres de columna (ej .: firstName, postCategoryId, postPhotoId)

Entonces con esto, podría usar una sintaxis similar en el controlador.

$result = Post::where(''postCategoryId'', ''4'')->get();

¿Hay alguna recomendación de Laravel para esto? ¿Puedo continuar con estas convenciones de nombres?

Si alguien tiene mejores sugerencias, estaré encantado de escucharlas. ¡Muchas gracias!

Answer 1

Laravel tiene su propia convención de nombres. Por ejemplo, si el nombre de su modelo es User.php , Laravel espera que la clase ''Usuario'' esté dentro de ese archivo. También espera que los users hagan users tabla para el modelo de User . Sin embargo, puede anular esta convención definiendo una propiedad de tabla en su modelo como,

    class User extends Eloquent implements UserInterface, RemindableInterface {
        protected $table = ''user'';
    }

De la documentación oficial de Laravel:

Tenga en cuenta que no le dijimos a Eloquent qué tabla usar para nuestro modelo de Usuario. El nombre plural en minúsculas de la clase se usará como el nombre de la tabla a menos que se especifique explícitamente otro nombre. Entonces, en este caso, Eloquent asumirá que el modelo de usuario almacena registros en la tabla de usuarios. Puede especificar una tabla personalizada definiendo una propiedad $table en su modelo

Si va a usar la id de la tabla de usuario en otra tabla como una clave foránea, entonces debería ser snake-case como user_id para que pueda usarse automáticamente en caso de relación. De nuevo, puede anular esta convención especificando argumentos adicionales en la función de relación. Por ejemplo,

    class User extends Eloquent implements UserInterface, RemindableInterface {
        public function post(){
            return $this->hasMany(''Post'', ''userId'', ''id'');
        }
    }

    class Post extends Eloquent{
        public function user(){
            return $this->belongsTo(''User'', ''userId'', ''id'');
        }   
    }

Documentos para la relación elocuente de Laravel

Para otras columnas en la tabla, puede nombrarlas como desee.

Te sugiero que revises la documentación una vez.

Answer 2

Las convenciones de nomenclatura de tabla predeterminadas pueden causar conflictos con la instalación de varios paquetes que pueden tener incidentalmente los mismos nombres de clase. Una solución sería nombrar las tablas como: [proveedor]. [Paquete]. [Clase], que está en línea con cómo se aplica el espacio de nombres en Laravel.

Editado : no se recomienda el uso de puntos en los nombres de las tablas. ¿Habría una convención alternativa para garantizar que los desarrolladores de una aplicación construida modular no tengan que preocuparse por los nombres de tablas existentes?

Answer 3

No estoy de acuerdo en general con estos ejemplos que ambos han mostrado aquí.

Está limpio si echas un vistazo a la documentación oficial de Laravel, especialmente en la sesión de relación de Eloquent ( http://laravel.com/docs/4.2/eloquent#relationships ).

Los nombres de las tablas deben estar en plural, es decir, la tabla de ''usuarios'' para el modelo de Usuario.

Y los nombres de columna no necesitan estar en Camel Case, sino en Snake Case. Vea que ya está respondido: convención de nombre de campo de base de datos / modelo en Laravel?

Es muy habitual que pueda ver que es como el RedBeanORM: el Snake Case para columnas, incluso si prueba otro. Y se aconseja evitar repetir los nombres de las tablas con columnas debido al método que puede invocar desde el objeto Modelo para acceder a sus relaciones.