Define database schema

[pgesek]

@oskarhinc @afijal please take a look at the schema in the PR and let me know what if you think

[oskarhinc]

After analyzing the schema, I've got a few questions and suggestions:

1. How SystemAccount entity should be used? Shouldn't it be connected to some special user or even replaced by it?
2. Do Organisation and Service entities require updatedAt property, as there is a metadata anyway?
3. _taxstatus and _taxid might use camelCase, like the rest of the properties.
4. Wouldn't using an enum for service type simplify its management?
5. Why is there address1? If we'd like to store more addresses should it be a list of them? If there'll be only one, then we can just use address name, but if there's a reason to specify that it's the first address, I think name firstAddress is more natural.

[pgesek]

1. System Account represents a partner that logs into the system. Each user should be connected to a system account (at the start we plan to have only 1 user per account)
2. It will be easier to retrieve/compare this info rather than do queries on the change log (which metadata is)
3. yes, they should
4. perhaps, although I don't know the values for it at this point
5. If you mean the location entity - address1, city, zip were included by mistake. If you mean the address entities, address1 is the naming that follow HSDS (https://openreferral.readthedocs.io/en/latest/hsds/reference/). Address1 usually refers to the first address line (street address), address2 to the second line etc. HSDS deprecated other address field in order to use fields like city. zip, country etc. I think it's best if we stick to their naming of the field, which is still address1.

[oskarhinc]

@pgesek Thanks for the clarification! I've merged the pr.

[pgesek]

@oskarhinc - do you think we should close this ticket?

[oskarhinc]

Sure, I'll close it