La experiencia cuenta mucho, pero en términos de diseño de tablas, puede aprender mucho de cómo operan los ORM como Hibernate y Grails para ver por qué hacen las cosas. Adicionalmente:
Mantenga diferentes tipos de datos separados: no almacene direcciones en su tabla de pedidos, enlace a una dirección en una tabla de direcciones separada, por ejemplo.
Personalmente, me gusta tener un número entero o una clave sustituta larga en cada tabla (que contiene datos, no aquellos que vinculan diferentes tablas, relaciones e, g., M: n) que es la clave principal.
También me gusta tener una columna de marca de tiempo creada y modificada.
Asegúrese de que cada columna que haga "where column = val" en cualquier consulta tenga un índice. Quizás no sea el índice más perfecto del mundo para el tipo de datos, sino al menos un índice.
Configura tus claves foráneas. También configure las reglas ON DELETE y ON MODIFY cuando sea relevante, ya sea en cascada o en nulo, dependiendo de la estructura de su objeto (por lo que solo necesita eliminar una vez en la 'cabeza' de su árbol de objetos, y todos los sub-objetos de ese objeto obtienen eliminado automáticamente).
Si desea modularizar su código, es posible que desee modularizar su esquema de base de datos; por ejemplo, esta es el área de "clientes", esta es el área de "pedidos" y esta es el área de "productos", y use tablas de unión / enlace entre ellos, incluso si son relaciones 1: n, y tal vez duplican la información importante (es decir, duplican el nombre del producto, el código, el precio en su tabla de detalles de pedido). Lea sobre la normalización.
Alguien más recomendará exactamente lo contrario para algunas o todas las anteriores: p: nunca hay una forma real de hacer algunas cosas, ¡eh!