Prev: Virtualization
Next: SQL Server cluster failover slow problem
From: Miguel F on 20 Jul 2010 21:39
as I can find the tables have a view? that is, if I have "select * from
vFacturas" how I can find the fields and tables for each field?

thanks


From: Steen Schl�ter Persson on 21 Jul 2010 05:30
You can use sp_help and/or sp_helptext to get some info.

E.g. sp_help vFacturas will give you some info.

For more possibilities you can take a look in BOL because depending on how
you want to use the information there might be other options.



--
Regards
Steen Schl�ter Persson (DK)

"Miguel F" <miguel(a)espectaculosfominaya.com> wrote in message
news:%235N6eWHKLHA.5668(a)TK2MSFTNGP04.phx.gbl...
> as I can find the tables have a view? that is, if I have "select * from
> vFacturas" how I can find the fields and tables for each field?
>
> thanks
>


From: Eric Isaacs on 21 Jul 2010 13:00
Another proactive thing you can do is to name your fields prefixed by
the table names:

CREATE TABLE Sample(
SampleID INT IDENTITY PRIMARY KEY,
SampleName VARCHAR(50),
SampleCreateDate DATETIME
)

Whenever you have a view that incorporates these fields, you'll
instantly know where it comes from, (but not necessarily how it got
there.) This also helps prevent aliasing of your field names to keep
them unique, which can easily cause the mapping of the fields to
become obscured.

-Eric Isaacs
From: Erland Sommarskog on 22 Jul 2010 05:37
Eric Isaacs (eisaacs(a)gmail.com) writes:
> Another proactive thing you can do is to name your fields prefixed by
> the table names:
>
> CREATE TABLE Sample(
> SampleID INT IDENTITY PRIMARY KEY,
> SampleName VARCHAR(50),
> SampleCreateDate DATETIME
> )
>
> Whenever you have a view that incorporates these fields, you'll
> instantly know where it comes from, (but not necessarily how it got
> there.) This also helps prevent aliasing of your field names to keep
> them unique, which can easily cause the mapping of the fields to
> become obscured.

I recommend against that.

There are situations when adding a prefix is a good idea. For instance,
don't call a column ID, but call it OrderID, CustomerID etc. And then use
these names everywhere you have an order id, customer id etc. But don't
call the CustomerID in the Orders table OrdersCustomerID. The exception
is when you want to describe some special usage, for instance when there
are two customer-id columns in the same table.


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

 | 
Pages: 1
Prev: Virtualization
Next: SQL Server cluster failover slow problem