I have a registration form for users that can insert multiple addresses.
I take User as an entity but I am not sure about collections of addresses. if it was only one address I would take it as ValueObject but I am not sure what about collections of addresses. if I have to take them as ValueObject how can I store them in tables, do I need to define a new table for it, if Yes they get Ids that are wrong for ValueObject.
Collection of addresses is fine as a value object.
The fact that your storage implementation requires multiple rows (with identifiers?) is an implementation detail of storage that has nothing to do with the model of your domain.
Related
I have following two entities, where a person address is kept in a separate table because a person can have multiple addresses.
The mailing address however is one of the multiple addresses stored in address table, which is to be referred in person table.
Can following relationship exist?
The answer to your direct question is "Yes". However, you cannot declare the model only using create table because:
Declaring the foreign key address.person_id requires that the person table already exist.
Declaring the foreign key person.mailing_address requires that the address table already exist.
Hence, to implement the model, you need to use alter table to add one or both of the constraints after both tables are created.
Is this the model you want? One feature of an address is that multiple people can have the same address. Your model does not allow that. To handle this, you would typically have three tables:
Person
Address
PersonAddress
The third table has one row for each person/address pair. It can also have other information such as:
Type ("mailing" versus other types)
Effective and end dates.
Perhaps other information.
If you want to guarantee uniqueness of the "mailing" address in such a model, many databases support filtered unique indexes, to ensure there are no duplicate mailing addresses.
I'm not sure why you have person_id as an fk on address but that doesn't look correct. There are lots of correct ways to model this and the best one for you will depend on you particular circumstances - but a couple of options are:
If you know all the types of addresses there can be then add multiple address fk fields to the person e.g. billing address, shipping address, etc. This makes querying quick and simple but is inflexible: adding a new address type in the future is relatively complex to implement
Add an intersection table with fks for person and address and an address type field. This has a slight overhead when it comes to querying but has the advantage if being very flexible: adding a new address type is trivial
I want my model to have an array of other model's instances. Let me explain.
I have a Company model which has a localizations field which is supposed to be a set/array of addresses. Since one address can only be for one Company, M2M relationship seems wrong here.
When Company gets deleted, all of its localizations should also be deleted.
How do I accomplish that? (I don't use Postgres)
In this situation you want a ForeignKey (which is a many-to-one relationship). See the code below:
class Company(models.Model):
...
class Address(models.Model):
company = models.ForeignKey(Comapny, on_delete=models.CASCADE, related_name="localizations")
address_line_1 = models.CharField(max_length=255, blank=False)
# Other fields you want
...
Each Address points to one Company instance. But there is no limit on how many Addresss can point to a Company. In this sense, a company "has" many addresses.
The related_name="localizations" argument, means that you can do company.localizations to get an array of the Address instances that point to that company.
Finally, on_delete=models.CASCADE means that if you delete a Company instance, the Address instances that point to it will also be deleted.
I have a model called Addresss which as the name sounds, is a list of addresses.
These addresses can belong to a Client and a client can have many of these addresses.
To link these addresses to the client, I will simply have a table called ClientAddress with 3 columns: id, client_id and address_id.
Is this an example of a one to many or a many-to-many relationship? I currently have it setup as a ManyToMany relationship in Phalcon however I'm not sure if it should actually be One to Many.
It's a one-to-many relation. One client (can) have multiple addresses. One address belongs to only one client.
Regarding your clientAddress table, I'd get rid off it as you can store the client id on the adress table.
If, as your tags suggest you're using phalcon and decide do go with phalcon's orm you should have a look at the documentation : Working with Models
Its all depends how you are thinking about your Entities
Lets start from Client
We would like to store information about Client. Now if our Client has only one specific Location then we have two options. We can directly store the Address information in same table as-
clients table
id, f_name, l_name, address, current_city, home_city, etc....
In this case there is nothing about Relation
If you are interested then you can split this table and store Location information on other table which you may name as addresses. Then the Relation between Client and Address will be one-to-one relation.
Now, if our Client has different office on different Location then it is mandatory to store Location information on different table. Then the Relation will be one-to-many as our Client has different `Location'.
Now, if we have many Client on same Location (same building may be) and our Client has many office in many Location then it will be as many-to-many relation. As Client hasMany Address and Address hasMany Client we new a pivot or intermediate table to hold our Relation information.
It depends on quite how complex your model is likely to become.
Suppose your "clients" are branches of a national company. Eech "client" may then have multiple adrresses - delivery address and billing address for instance. And equally, since the accounts-payable function may be centralised to either a regional or national branch (which may itself have, or not have a "delivery address)" the billing address is likely to be shared amongst many "clients."
So, in this scenario, many-to-many.
I am designing a database and initially I setup addresses separate from orders so the orders table just has a billing id and address id reference and the actual address are stored in the address table.
However the more I think about this i am not sure there is any real advantage to putting address into their own table.
The main reason is that a order is self contained meaning that the address is only valid for that order.
Having address linked instead of on the order record leads to some complications when updating addresses. Say if we have two orders from one customer linked to the same address and he wants the address changed on one order but not the other a new address. The application now needs to create a new address in the address table and change the linked address on the order (you can't just change the address because it would change it for both linked orders).
You also have to have code in your application that links new orders to addresses already in the database (and that only works for orders where the addresses are identical or nearly identical).
The only advantage I see right now to having order addresses in their own table is so the billing address and shipping address are not duplicated for every order.
On the surface it seems like preventing billing and shipping address data duplication isn't worth the extra code needed to make storing addresses in their own table work.
Any recommendations on how to handle this? Is there some big advantage to handling the addresses in separate tables that I am missing?
It sounds like what you want (ideally) is for the order to be linked to the address as it was at the time of the order.
There are two main ways to implement this - either the order includes all of the address information within its own structure, or you implement the address table as a temporal table, and ensure the order has appropriate datetime information to locate the correct address rows when queried.
Which one you implement depends on how you wish to handle updates - both models may have issues, depending on whether in-flight orders should/should not be updated.
If the address is linked to that order only, then it should be part of the order, not in its own table.
Unless your database has logic relating to an actual address entity, it doesn't need to be in its own table even if you'll want to add the ability to store address information for other sorts of entities.
Consider a system which has classes for both letters and people; both of these classes compose an address. When designing a database for the system it seems sensible to have a separate schema for the address but this leads to an issue; I don't know how to have a foreign key in the address table cleanly identify what it belongs to because the foreign key could identify either a letter or a person. Further more I expect that further classes will be added which will also compose an address.
I would be grateful for design patterns addressing this kind of design point.
Best Regards
I don't know how to have a foreign key
in the address table cleanly identify
what it belongs to because the foreign
key could identify either a letter or
a person.
It sounds like you have got that the wrong way around. There would be no foreign key in the address table; rather, the letters table would have a foreign key referencing the address table and the persons table would also have a foreign key referencing the address table.
In SQL, the REFERENTIAL_CONSTRAINTS view in the Information Schema catalog will tell you which tables are referencing the address table.
In our shop we regularly debate whether an address should be modelled as an entity in its own right. The problem with treating an address as an entity is that there is no reliable key beyond the attributes themselves (postal code, house name or number, etc) and many variations can identify the same address (I can write my home address twenty different ways). Then you need to consider post office boxes, care of addresses, Santa Claus, etc. And the Big Question: do you allow an address to be amended? If someone moves house, do they keep the same address entity with amended attributes (that way all linked entities get the address change) or do you lock-down addresses' attributes and force the creation of a new address entity then relink all the referencing addresses to the new one (and do you delete the now-orphaned address entity and if yes then why did you bother to replace it...?) But your application still needs to allow an address to be amended in case the post office changes it in real life, but how to you prevent this ability from being misused i.e. using it for aforementioned illegal house moves? You can use a webservice to scrub your address data so that is is correct but an external system way have less clean data and therefore you can't get your address entities to match anymore...?
I like to keep it simple: an address is a single attribute being the plaintext you must put on an item of mail for it to be delivered by the post office to the addressable entity in question; it is not an entity in its own right because it lacks an identifier. For practical reasons (e.g. being able to print it on an address label), this single attibute is usually split into subatomic elements (address_line_1, address_line_2, ... postal_code, whatever).
Because most SQL products lack support for domains, I have no problem duplicating the column names, data types, constraints, etc between for each table that models an addressable entity.
Surely the foreign keys should be from the Letter and People tables referencing the primary key on the Address table?
So, the Letter table contains an AddressId column referencing the Id on the Address table, as does the Person table, and any future classes which compose an address.
If Letters and Persons compose multiple addresses, then intermediate link tables will be required.