@jcolebrand Actually, restore is a SQL keyword. Maybe it needs to have a specific tag blurb explaining the function of the keyword and referring to a restoring tag that explains backup/restore. Also posts with restore would have to be re-tagged appropriately.
@AaronBertrand You're the reason I'd even heard of Qure. Is the licence that we get with SQL Sentry a perpetual licence or is it just a one-time licence for the instance monitored by Sentry within the boundaries of that bundle?
@jcolebrand I will. There are one or two other tag removals that I had similar issues with. For example schema is a specific concept and reserved word in T-SQL.
@JackDouglas Imagine a question like 'RESTORE DATABASE fails with xyz error when I use the command from a SQL script but i can resore fine from SSMS. What am I doing wrong?'
@JackDouglas What I mean is that one of the suggestions on the meta question was to delete schema, because people were equating it to database-design. My comment is that schema means something quite specific W.R.T. various database platforms, and is a reserved word in some dialects of SQL, so it isn't a good idea to ban the tag.
@ConcernedOfTunbridgeWells but the specialized uses of the word schema are not big enough categories to merit their own tag, so we don't want them used as tags anyway
@JackDouglas I'm not keen on banning tags that correspond to SQL keywords, because people asking questions on those keywords may well find it quite confusing if their tag gets aliased to something wierd.
If I asked a question like 'How do I check for the existence of a schema before I create it?' and found my tags aliased to database-design it might be a bit odd, and that tagging would be wrong.
so semantic precision is important in order for it to be properly understood by you, but broad enough so that someone like me who may not be able to understand the differences between "schema" in Oracle and Microsoft SQL Server (or however @jcolebrand likes it taxonomized) can still get their crap answered
@swasheck More like we don't want to proliferate bans on tags that people might use reasonably.
A given tag could have multiple meanings, and those meanings could be explained in the tag blurb. In more extreme cases the tag blurb could have specific admonishments to use other tags in particular cases.
@ConcernedOfTunbridgeWells Right. But it's probably too narrow to boil tags down to either "processes" or "things." It seems more like that's the ideological debate.
@JackDouglas If I wanted to ask a question about creating a schema and tried to use schema then I would get it aliased to database-design, which is flat out wrong.
@JackDouglas Now we're expecting people asking questions to understand how the tag taxonomy works in order to avoid elephant traps that would result in incorrectly tagged questions.
@ConcernedOfTunbridgeWells my point is that either way the question will be incorrectly tagged - if it is about the Oracle or SS keyword that it shouldn't have the tag
try asking a Q and typeing "managemen" into the tags - you can see at a glance that it is a synonyn - this already starts the process of educating the user
I'm mostly an application developer but find myself having to do all the up-front database work for my current project (btw... its MS SQL Server 2008). As a first decision, I'm trying to figure out whether to divide my state using seperate Databases or using seperate Schema's in the same database...
I was considering using "Safety" as a new schema name in SQL Server. In SSMS, the term Safety is colored as a keyword, but this term is not listed as a reserved keyword in the BOL. The database does not complain if I create and use it, but is there any reason why I should avoid using it?
When it comes to the dbo schema:
Is it a best practice to avoid using the dbo schema when creating database objects?
Why should the dbo schema be avoided or should it?
Which database user should own the dbo schema?
I am not able to understand concept and usage of schema in Postgresql. I have no idea how it can affect my database design.
Why should I use it?
Can it affect me in future if I decide to not think about them right now and worry about them later?
Explanation with an example will be nice.
I'm going to go out on a limb here fully expecting this to get down-voted since this is a DBA-focused group.
I agree that using strict foreign keys is the best decision in most scenarios. However, there are some cases where foreign keys cause more problems than they solve.
When you are deali...
We have several databases under development and I would like to start using SQL Server schemas for permission management and logical grouping of database objects. Under Schema Properties there is explicit permissions like
Alter
Control
Delete
Execute
...
What is the hierarchy of these permiss...
When I attempt to change the default schema of the dbo in SQL Server Management Studio, the ALTER fails and states that the dbo account's schema cannot be changed. Are there any tricks that can make is possible to change the the dbo default schema of "dbo" to "xxx"?
Thank you!
@Jackdouglas - maybe half a dozen on the first two pages of questions tagged schema, although they're far outnumbered by the ones on data modelling. As a subjective view, I'd say it would have been better to re-tag the ones about data models with database-design and leave schema alone.
@JackDouglas However, we do have a large community of users who care[tm] to do it.
You don't need all that much rep to re-tag a question. SE sites tend to accumulate a community of volunteer janitors to do it. You don't have to do the work all by yourself.
@JackDouglas - Is the core of your reasoning that Schema is too narrow to be a tag or that it can mean different things on different database platforms?
Delete schema.
It is too generic to be useful. Most questions tagged with this are better served by database-design.
Vote here on the synonym: http://dba.stackexchange.com/tags/database-design/synonyms
@LeighRiffel My instinct would be yes to (trigger, view, join) and no to (insert) but I guess it should depend on a review of the questions with those tags
@JackDouglas You are welcome, that statement seemed to de-legitimize the site and the DBA profession in general, although I don't think that was the intention.
But triggers are implemented considerably differently in different databases just as schemas are. I do understand where you are coming from, but I think I'm with @ConcernedOfTunbridgeWells on this one.
@LeighRiffel I think this also tangles with a 'what's in a name' problem that DBA (arguably at least) has. DBA.SE's definition of 'on topic' also explicitly includes advanced database development topics, and there has been much wailing and gnashing of teeth about the name confusing people.
@ypercube It's not the only word that can have multiple meanings, I was using it as a specific example because it can have a meaning where the term schema refers to a specific feature but people could use it to mean database-design
I'm arguing that it is too localized - and that the added complication of the clash with the generally accepted meaning of schema means the bar should be even higher before we accept it as a 'good' tag
@JackDouglas That's not an unreasonable view, although I suspect that the correct approach to it is to allow the tag nazis to re-tag the questions appropriately.
@JackDouglas I'm happy to do some tag nazi work, and I imagine that some of the other regulars would be quite happy to do that as well. I don't think you need all that much rep to be able to re-tag questions.
@JackDouglas Shall I make up the meta question then?
@JackDouglas Is schema actually still usable or is it impossible to tag a question with it without the question being automatically re-tagged to database-design?
@ConcernedOfTunbridgeWells given that meta shows we have no consensus to have the synonym, I've removed it. If things change on meta I may have to reinstate of course
@JackDouglas That's fine. In the interim my preferred approach is to split out the questions with schema into legitimate ones about schemas and re-tag the data modelling questions with database-design. Anybody particularly object to that?
@JackDouglas Don't worry at this point. I think there about 60 with schema and I'd rather than go through that than through all 352 questions tagged database-design
merge database-restoring and restore
this is a no-brainer, right?
I was considering using "Safety" as a new schema name in SQL Server. In SSMS, the term Safety is colored as a keyword, but this term is not listed as a reserved keyword in the BOL. The database does not complain if I create and use it, but is there any reason why I should avoid using it?
I am not able to understand concept and usage of schema in Postgresql. I have no idea how it can affect my database design.
Why should I use it?
Can it affect me in future if I decide to not think about them right now and worry about them later?
Explanation with an example will be nice.
I'm going to go out on a limb here fully expecting this to get down-voted since this is a DBA-focused group.
I agree that using strict foreign keys is the best decision in most scenarios. However, there are some cases where foreign keys cause more problems than they solve.
When you are deali...
Delete schema.
It is too generic to be useful. Most questions tagged with this are better served by database-design.
Vote here on the synonym: http://dba.stackexchange.com/tags/database-design/synonyms
