Search:
Search questions and share your knowledge with the world here on Questionpoint.

:: Categories ::

Interview Question in SQL Server Data Services (SSDS)

Interview Question :: Keep it in tables or create objects

I recently developed an application that gathers lots of remote data from two very large database servers, runs some intensive calculations using SQL queries and VB code, storing the intermediate values in local tables, and then generates some reports. It took about 4 weeks to complete by myself working 4 hours a day.

It runs very nicely with minimal user input. But I was thinking recently that if I wanted to have done something more than an ad-hoc design, I probably should've made some nice, organized class diagrams for a domain model and then used these diagrams to implement classes that would hold the data while it was being worked on (via clean class methods and services).

But my question is: wouldn't this be overkill? The data is already modeled on the two servers. All I'm doing is bringing objects into memory, executing code instead of queries, and spitting the output into tables anyway because I need to run reports.

Which way is better?

Answers to "Keep it in tables or create objects"

RE: Keep it in tables or create objects?
It depends. As a rule, you want the simplest solution that uses the least resources. I had a similar project to what you describe that I did in SQL Server 2000 several years back and I used the same approach you used; lots of queries, lots of VB Script. If I had the tools available in ADO.NET at the time, I probably would have taken the second approach you describe. My solution was very complex and small changes in one place had huge consequences throughout the solution; a consolidated approach such as can be created with DLLs and compiled code would have been infinitely preferable.
Vote for this answer ::

RE: Keep it in tables or create objects?
I'd keep the SQL queries for now. No need to redesign the whole working app without adding additional user features. Perhaps when you've got enough changes to make, and there are always changes to make in the future, a revamp using objects and a plan before you actually start to add the changes would be beneficial.
Vote for this answer ::

RE: Keep it in tables or create objects?
I think the answer to this is dependent upon your area of expertise, your willingness to recode the application, and whether you expect the code to be reviewed and/or maintained by someone else in the near future. I have found that VB isn't really the best language for object oriented programming, so it may not be worthwhile to recode it. If you do go to that trouble, you may want to consider doing it in C# or another language that is better suited to OOP.
Vote for this answer ::

RE: Keep it in tables or create objects?
a programmer to programmer question and answer :) actually, your approach was not that bad, if you want to create the objects, it was almost 75% recoding of the application, if you wish to keep it then almost no effort to be done, just enhancements. actually it is better to create objects, but its just better that you have think of this before you have started to code the application.
Vote for this answer ::

Notify me whenever an answer is posted for this question Update Alert Setting

Top Tags

- Sharepoint Developer Interview Questions - Java Interview Questions - J2EE Interview Questions - ASP.NET Interview Questions - MOSS 2007 Interview Questions - WPF Interview Questions - Microsoft CRM Interview Questions - Technical Interview Questions for Programmers

Search questions and share your knowledge with the world here on Questionpoint.

:: Categories ::

Interview Question in SQL Server Data Services (SSDS)

Interview Question :: Keep it in tables or create objects

Top Tags