July 14, 2016 at 9:51 pm
Comments posted to this topic are about the item What Happens When Naming Types
July 14, 2016 at 9:52 pm
Thanks Steve, easy one to end the week on.
...
July 15, 2016 at 12:24 am
This was removed by the editor as SPAM
July 15, 2016 at 2:47 am
Why would this be unwanted behavior?
July 15, 2016 at 3:28 am
This was removed by the editor as SPAM
July 15, 2016 at 3:34 am
Stewart "Arturius" Campbell (7/15/2016)
Mighty (7/15/2016)
Why would this be unwanted behavior?not neccessarily unwanted, but could be confusing for another to support, e.g.
CREATE SCHEMA Steve AUTHORIZATION dbo;GO
CREATE TYPE Steve.Steve FROM NUMERIC(4, 2);
CREATE TABLE Steve.Steve (
id INT,
Steve Steve.Steve );
Now also create a database called Steve and we're all set 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 15, 2016 at 6:01 am
Nice question. Get the brain moving. Thanks.
July 15, 2016 at 6:08 am
Koen Verbeeck (7/15/2016)
Stewart "Arturius" Campbell (7/15/2016)
Mighty (7/15/2016)
Why would this be unwanted behavior?not neccessarily unwanted, but could be confusing for another to support, e.g.
CREATE SCHEMA Steve AUTHORIZATION dbo;GO
CREATE TYPE Steve.Steve FROM NUMERIC(4, 2);
CREATE TABLE Steve.Steve (
id INT,
Steve Steve.Steve );
Now also create a database called Steve and we're all set 😀
What about placing the database on a linked server that's also named Steve? 😛
SELECT s.Steve
FROM Steve.Steve.Steve.Steve s
ORDER BY s.Steve;
And yes, the linked server connection would be made using a remote login Steve to the server Steve and instance named Steve.
Without bringing up the name of the domain, I think this is more than enough to thoroughly confuse the unfortunate support person.
July 15, 2016 at 10:12 am
It's a strange inconsistency, in my mind. We put all objects in sys.objects, except a few like Types. So we can have naming collisions. If you're a C/C++ person, you probably don't care, and you wonder why we don't have procs separate from tables.
If you're a consistency person, you think this isn't good since I could have two objects with the same name.
July 15, 2016 at 11:13 am
Koen Verbeeck (7/15/2016)
Stewart "Arturius" Campbell (7/15/2016)
Mighty (7/15/2016)
Why would this be unwanted behavior?not neccessarily unwanted, but could be confusing for another to support, e.g.
CREATE SCHEMA Steve AUTHORIZATION dbo;GO
CREATE TYPE Steve.Steve FROM NUMERIC(4, 2);
CREATE TABLE Steve.Steve (
id INT,
Steve Steve.Steve );
Now also create a database called Steve and we're all set 😀
It doesn't end at just one database named steve.
Check out this presentation by Rob Volk. http://dba.sqlpass.org/MeetingArchive.aspx (Look for "Revenge the SQL")
Specifically the recorded presentation and demos.
mms://passmedia.sqlpass.org/share/dba/RevengeTheSQLPart2_01092013.wmv
http://passfiles.sqlpass.org/vc/dba/RevengeTheSQL2_PASSVC.zip
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 15, 2016 at 11:14 am
CREATE TYPE Steve AS TABLE (id int);
GO
CREATE PROCEDURE Steve AS SELECT 1;
GO
CREATE SCHEMA Steve;
GO
GRANT EXECUTE ON Steve TO public;
This succeeds and grants permission execute permission to Steve. Which Steve? The procedure.
The GRANT must be qualified to grant to anything other than an object:
GRANT EXECUTE ON OBJECT::Steve TO public;
GRANT EXECUTE ON TYPE::Steve TO public;
GRANT EXECUTE ON SCHEMA::Steve TO public;
Technically, types, objects and schemas occupy different namespaces. In most cases, we don't have to qualify them because the context determines the namespace. Despite granting execute permission on all three objects above, I can actually only use one of them with the EXECUTE statement.
I can see valid reasons for having the same name on some of these objects. Suppose that an organization is tracking sales, and that organization's naming standards specify that all database objects are named in the singular without prefixes or suffixes indicating the object type. In that case, the organization might have a schema named Sale, a table named Sale and a user-defined table type named Sale. Put in context with the rest of the database and a consistent application of the naming standard, this is not necessarily confusing.
July 15, 2016 at 12:07 pm
Could be an interview question. Ideally the candidate should ask "who in his right mind would even try to do this ?" Followed by "I don't even care if it is at all permitted. I hope I never have to maintain code written like this".
July 18, 2016 at 1:05 am
Nice one: sys.types vs sys.objects
T.a.
Iulian
July 24, 2016 at 6:22 pm
Steve Jones - SSC Editor (7/15/2016)
It's a strange inconsistency, in my mind. We put all objects in sys.objects, except a few like Types. So we can have naming collisions. If you're a C/C++ person, you probably don't care, and you wonder why we don't have procs separate from tables.If you're a consistency person, you think this isn't good since I could have two objects with the same name.
Talking about consistency:
Index names must be unique within a table, unique key names must be unique across the whole database.
_____________
Code for TallyGenerator
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply