back end table naming

[Tony Toews [MVP]]

While there may be little difference between a query or table as a
data source when using a form or report wizard, there surely *is* a
difference between two objects of similar name and function. Say you
had a query that aliased some fields and had some calculated fields
for a single base table. To me, the easiest thing to do is to have
tblMyTable and qryMyTable. But you'd have to put that information in
the verbose part of the name itself.

Sure, but I would name such a query to do with it's functionality or the name of the
form or report it's used on. One such example would be Overdue Items. Now that's
based on other queries and is a Union query so that's a bad example.

In SQL Server, I often have the table linked, but also will link a
view on the same table that does certain things (in one legacy app,
the base tables names have been updated to be correct, but the app
hasn't been updated yet, so I use a view with the fields aliased for
compatibility with the old application objects). One I call
tblMyTable and the other vblMyTable. Yes, sort of silly, but it lets
me know that one is the view of the table and the other is the table
itself.

You would probably name it something like MyTable and MyTableView.

Quite likely but I'd have to think about it.

I'm sure you're happy with your approach and would hate mind. And
vice versa.

<chuckle> Absolutely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[a a r o n . k e m p f]

Tony;

you're a known stalker and liar.
Please stop polluting my newsgroup with your filth.

-Aaron

 

[Arvin Meyer [MVP]]

message
how about the # of columns?

how about having 32k objects PER DATABASE

Anyone who designs tables with more than a few dozen columns has no idea how
to design a database. Every database system in existence can accommodate
more than 5 times the number of required columns.

Access can handle 32,768 objects either in an MDB or an ADP. But then, you
probably know that.

 

[Troll Chaser]

message

you're a known stalker and liar.
Please stop polluting my newsgroup with your filth.

 

[David W. Fenton]

[sarcastically, to Aaron:]

Access can handle 32,768 objects either in an MDB or an ADP. But
then, you probably know that.

I don't think you're using the word "probably" the way *I'd* use it.

 

[a a r o n . k e m p f]

Arvin;

So the database format for MS project-- it is several hundred columns
wide, right?

So you're saying that you're a better DB Developer- even though you're
a Jet NooB-- than the people that designed MS Project?

I'm not so sure that I agree with your general premise.
Number of Columns shouldn't always be minimized-- it depends on what
you're trying to do.

A lot of times, it is simpler to keep multiple pieces of data - in the
same grain- in the same table.

SQL Server expanded on the ability to do this with 'sparse data' in
SQL 2008.

Now why is it that MS would make SQL Server _EVEN_BETTER_ at Wide
tables-- if this was somehow improper?

I've worked on ~~100 databases the past decade with more than ~~100
columns in a handful of tables.

Sometimes it is proper, sometimes, it is excessive.

But being stuck with a piece of junk database doesn't help me to meet
the needs of my clients.
That is why I choose SQL Server for almost everything I do.

 

[a a r o n . k e m p f]

re: required to be civil and not liable anyone

what are you stalking about?