Hello,For many years I have always used id's (auto increment integers) for everything rather than storing data on the table.Let me explain by a very simple example, lets say I have a Customer table, and for each customer I need to know their title (i.e. Mr, Mrs, Miss, Ms etc)So I would have tables likeCustomer----------IdFirst NameLast NameAddress Line 1Address Line 2Address Line 3Post Code / Zip CodeCustomerTitleIdCustomerTitle----------------IdNameSo CustomerTitle table contains all titles, and the Customer table is linked to it by the IdA senior guy in the office is arguing with the way we do things. Insisting that whilst we would still have the title table, we should not have an integer id on the CustomerTitle table (having the title name itself as the primary key), and on the Customer table we store the actual title.Whilst this example is very simple, another example was if we had County (or State) - my argument against this is what if we change the County on the lookup table (maybe it was misspelt) - then the one stored on the customer table would not matchI like the consistency of always having IDs and the example of the County is a good reason to do so. He is OK with Ids for some things (like linking to product table) but wants to mix and match which I don't like. Also we are using MVC which I find works well with Ids linking everything.I'm just wondering what others do? Do you ALWAYS have Ids or do a mix and match approach.What benefits do you see of the way you do things?Any benefits you can see I have missed on using Ids all the time?
↧