I have tended to steer clear of calculated fields in Access. Now at the start of my journey of migrating data to SQL server, I notice it is possible to create calculated columns there too.
Are these a good idea? Any insights, tips and advice gratefully received!
Alex Lewis
@Reply 13 days ago
What are you trying to do calculations on?
David OrrOP
@Reply 12 days ago
Hello Alex, in Access I have a query that concatenates contact details in a range of ways, e.g. First + Last, Last + First, Title + First + Last, Address1 + Address2 + PostalTown + County + Postcode - for convenience and consistency with, for example receipts, mail merge, lookups and so on.
Alex Lewis
@Reply 12 days ago
You can concatenate column values using computed columns in SQL Server. It’s basically the equivalent of string concatenation in Access. For example:
Sure, I can, but *should* I? Am I better to put this sort of data into a View or is it accepted as perfectly good practice to make use of calculated columns? Thank you.
That's a great question, and honestly, I hear this debate a lot, especially from folks moving from Access to SQL Server. While SQL Server computed columns certainly have their place, for things like formatting names, addresses, and other display-oriented values, I'd generally recommend putting that logic in a view or in your SELECT queries instead.
My rule of thumb is to keep your tables focused on storing the raw business data and let views handle presentation. That gives you more flexibility later if your formatting requirements change, and it avoids cluttering your tables with multiple variations of essentially the same information.
Computed columns aren't bad at all. They're useful when you have a calculation that should always be defined in one place, and there are even performance and indexing scenarios where they make sense. But for mail merges, receipts, lookup displays, and concatenated address blocks, a view is usually the cleaner and more maintainable approach.
If you need to preserve calculated values for historical or auditing purposes, that's a different discussion. Otherwise, I'd keep the tables for 'real' data and do the formatting at the view or query level. And, of course, make a backup before changing table structures, especially if your next customer lives on the International Space Station.
David OrrOP
@Reply 9 days ago
That’s useful. I will stick with queries/views for now as I explore and develop my knowledge and experience of this new world!
Thank you both.
Sorry, only students may add comments.
Click here for more
information on how you can set up an account.
If you are a Visitor, go ahead and post your reply as a
new comment, and we'll move it here for you
once it's approved. Be sure to use the same name and email address.