Home/ Questions/Q 103373
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T01:06:50+00:00

I’ve been trying to come up with a good design pattern for mapping data

  • 0

I’ve been trying to come up with a good design pattern for mapping data contained in relational databases to the business objects I’ve created but I keep hitting a wall.

Consider the following tables:

TYPE: typeid, description USER: userid, username, usertypeid->TYPE.typeid, imageid->IMAGE.imageid IMAGE: imageid, location, imagetypeid->TYPE.typeid

I would like to gather all the information regarding a specific user. Creating a query for this isn’t too difficult.

SELECT u.*, ut.*, i.*, it.* FROM user u INNER JOIN type ut ON ut.typeid = u.usertypeid INNER JOIN image i ON i.imageid = u.imageid INNER JOIN type it ON it.typeid = i.imagetypeid WHERE u.userid = @userid

The problem is that the field names collide and then I’m forced to alias every single field which gets out of hand very quickly.

Does anyone have a decent design pattern for this kind of thing?

I’ve thought about retrieving multiple results from a single stored procedure and then using a dataset to iterate through each one but I’m worried that some performance issues might bite me in the butt later. For example instead of the above query something like:

SELECT u.*, t.* FROM user u INNER JOIN type t ON t.typeid = u.usertypeid WHERE u.userid = @userid; SELECT i.*, t.* FROM image i INNER JOIN type t ON t.typeid = i.imagetypeid INNER JOIN user u ON u.imageid = i.imageid WHERE u.userid = @userid;

Does that seem like a decent solution? Can anyone foresee any issues with this approach?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Never use the SQL * wildcard in production code. Always spell out all the columns you want to retrieve.

    Then aliasing some of them doesn’t seem like such a huge amount of extra work.

    Re your comment asking for background and reasoning:

    • Sometimes you don’t really need every column from all tables, and fetching them can be needlessly costly (especially for large strings and blobs). There is no SQL syntax for "all columns except the following exceptions."

    • You can’t alias columns that you fetch using the wildcard. Once you need to alias any of the columns, you need to expand the wildcard to list all the columns explicitly.

    • If the table structure changes, e.g. columns are renamed, reordered, dropped, or added, then the wildcard fetches them all, by position as defined in the tables. This may seem like a convenience, but not when your application depends on columns being in the result set by a given name or in a given position. You can get mysterious bugs where your application displays columns in the wrong order (if referencing columns by position), or shows them as blank (if referencing columns by name).

      However, if the SQL query names columns explicitly, you can employ the "Fail Early" principle. This helps debugging, because it leads you directly to the SQL query that needs to be edited to account for the schema change.

    • 0