I must know the common practice for any domain implementation. Creating the company objects first, that require persistence or even the database schema first, producing it from an entity relationship diagram (and later on the ORM poco*'s)?
I will begin a solution, but I must know the most more suitable "pattern".
(*powered by NHibernate)
Is dependent on whether you are an item or relational modeler. Preference is determined in what you realize best.
I am an item person, so I'd say model the issue in objects after which obtain the relational schema from that.
I believe you will find plenty of issues around data that are not addressed by objects (e.g., indexing, primary and foreign secrets, normalization) that say you've still got some try to do when you are finished.
But any relational person will reason that they are primary and really should maintain the driver's chair.
I doubt that you will see a definitive response to that one. I do not believe there must be. There's an item-relational impedance mismatch that's real. Objects are instance-centric relational models are positioned-based. Both need consideration.
Common practice are generally, also it comes lower to the preferred choice of each implementer. As duffymo recommended you need to opt for the main one you realize best.
It is important to also consider what your family designs for dealing with data are. Getting something that's nicely patterned either in one, but very pricey when it comes to performance isn't a sensible choice. The total amount is somewhere in the centre.
Personally, i often be more conscious of the database aspect due to the fact databases are the type which are harder to scale. Keeping this really is mind when creating a database helps. It's not necessary to always result in the initial design following strict scaling rules, but getting it in your mind may help explore to create design choices that'll be the same as shooting yourself within the feet, when afterwards the requirement for scaling arises.