Microsoft's Inconsistencies In Windows
-
I disagree with the user-less data idea. All data belongs to someone and with the way security is evolving there is an increasingly strong focus on accounts (users), permissions, access control, etc. Think for example of how these days you select for whom you install an app (your own user account only or all users). It's all moving towards a secure account-based way of working. Take the cloud as another example and think of how the cloud will ultimately interact with local data (if at all). It will be on a user account level. I think (and fear) that the days of data just lying on a hard drive, free for all (or none), is numbered. So I don't think one should argue in that way. It's user data (even if you want to see the corporation as the user) and if you want to keep all user data away from all programs (the way Microsoft seems to want to) then the default location sucks. But aside from the storage point, nobody seems to find the other things irritating, which is interesting. :sigh:
I find the changes irritating. I also hate their documentation for several reasons: 1. All the pages that belong together almost always have to be searched for separately. 2. Most descriptions aren't descriptive enough. Some aren't descriptive at all. 3. Snippets may be illustrative, but it's the stuff in the unlit corners that bite you. Give me a whole damn sample! 4. Microsoft's search engines don't rank results very well. I usually have to wade through five or more pages of results before concluding that MS indexes articles based on other keywords. 5. Help includes too much material. If I'm working in .NET 2.0, I don't care about the latest whiz-bang memory-eater in .NET 4.0. Leave it out! More gets worse than better.
-- Ed Eaglehouse Languages broken with standards confused, No wonder I've got me the Programmer's Blues.
-
Thanks for the input, but I don't think it's crazy.
J4amieC wrote:
SQL Server is a service, and as such has no user, and no user data
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
J4amieC wrote:
This is ignoring the fact that where SQL Server stores this data is completely configurable.
Yes, I am ignoring this fact too, because the location I mentioned is the DEFAULT, so they're not practicing what they're preaching, BY DEFAULT. Even if I concede that SQL Server is special because it's a service, it's not like Microsoft is saying "Well, okay, if you're talking about a service then I guess it's okay for you to put it there". The point is, they don't want you to save your data under Program Files, service or not, but they do it themselves by default in SQL Server. I know I sound anal but I'm trying to rant here. ;P
Roelof De Villiers wrote:
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
That is not how it works. SQL Server is not meant for user. It is meant for other applications to use it to store data. The fact that SQL Server would scatter its data on user's application directories is complete madness. The application data folders for users are meant for data pertaining to a user. For instance, you may store there user preferences for your application (layout, colors, last opened files, etc.). As such, it is meant for end-user-oriented applications. SQL Server is a server application. The location you specify for SQL server is the default one and any serious installation will configure SQL Server data files to go elsewhere.
Roelof De Villiers wrote:
I know I sound anal but I'm trying to rant here.
Rant about what?
-
Roelof De Villiers wrote:
Of course it has users. The data stored in the databases are not for the sake of SQL Server and it doesn't belong to SQL Server. It's for the sake of users and it belongs to users. You can argue as to who those users are - the individual database users running queries or the administrator running the server for those database users - but there are users.
That is not how it works. SQL Server is not meant for user. It is meant for other applications to use it to store data. The fact that SQL Server would scatter its data on user's application directories is complete madness. The application data folders for users are meant for data pertaining to a user. For instance, you may store there user preferences for your application (layout, colors, last opened files, etc.). As such, it is meant for end-user-oriented applications. SQL Server is a server application. The location you specify for SQL server is the default one and any serious installation will configure SQL Server data files to go elsewhere.
Roelof De Villiers wrote:
I know I sound anal but I'm trying to rant here.
Rant about what?
Le Gauchiste wrote:
The fact that SQL Server would scatter its data on user's application directories is complete madness
Do you mean that SQL Server would never do this (because it will, if you accept its default location which sits under Program Files), or do you mean that accepting its default location would be madness (which is my point: the default location sucks)? I have read LOTS of documentation that say that an application should save its application data (let's talk about APPLICATION data then if you would like to argue that there is no USER data) under the common application data folder which would be "C:\Documents and Settings\All Users\Application Data" or similar. This is NOT the Program Files folder. So defaulting SQL Server's data folder to Program Files is not following their own standard. And this is the ONLY point I ever tried to make. I wasn't trying to debate whether one SHOULD save it there or not; that's another story.
Le Gauchiste wrote:
Rant about what?
Read my original post. I complained about Microsoft not sticking to their own standards, basically. The data storage point was one of four examples.
-
Le Gauchiste wrote:
The fact that SQL Server would scatter its data on user's application directories is complete madness
Do you mean that SQL Server would never do this (because it will, if you accept its default location which sits under Program Files), or do you mean that accepting its default location would be madness (which is my point: the default location sucks)? I have read LOTS of documentation that say that an application should save its application data (let's talk about APPLICATION data then if you would like to argue that there is no USER data) under the common application data folder which would be "C:\Documents and Settings\All Users\Application Data" or similar. This is NOT the Program Files folder. So defaulting SQL Server's data folder to Program Files is not following their own standard. And this is the ONLY point I ever tried to make. I wasn't trying to debate whether one SHOULD save it there or not; that's another story.
Le Gauchiste wrote:
Rant about what?
Read my original post. I complained about Microsoft not sticking to their own standards, basically. The data storage point was one of four examples.
SQL Server is a server application, not an end-user application. It is like you want SQL Server to act like Word or Excel.
-
SQL Server is a server application, not an end-user application. It is like you want SQL Server to act like Word or Excel.
Does it make a difference whether it's a server or end-user application? Funny, the documentation doesn't treat them differently. What is the fundamental difference that comes in as soon as someone mentions the words "end-user" or "front-end" or "UI"? Is it not just a mindset? Is there really some differentiating aspect that I'm missing? Anyway, I was talking about APPLICATION settings to make my last point, not USER settings. Do you believe that APPLICATION settings belong in Program Files?
-
Does it make a difference whether it's a server or end-user application? Funny, the documentation doesn't treat them differently. What is the fundamental difference that comes in as soon as someone mentions the words "end-user" or "front-end" or "UI"? Is it not just a mindset? Is there really some differentiating aspect that I'm missing? Anyway, I was talking about APPLICATION settings to make my last point, not USER settings. Do you believe that APPLICATION settings belong in Program Files?
end-user: Applications allowing users, always logged in, to perform work using business applications. For instance, Word, Excel, etc. server application: Applications usually running as soon as the computer starts up, and do not need any user actually logged in. Those applications rarely sport an end-user interface (except for managing the server, but not always required). Such applications include database servers, web servers, application servers. Those applications do not follow traditional conventions because their needs are specific to them. A database server, for instance, may require to have its data disks on special disk system, shared with other database servers, for redundancy and load balancing. Server applications can also be distributed (running on multiple machines) to handle heavy load, so having user directories as their directories does not make sense. front-end: A mix of end-user and server. In this case, you have back-end systems (one more for you to learn!), consisting of server applications, and a front-end, which allows users to perform various things that will interact with the server applications to extract and store data and other business-related tasks.. A front-end application may use local user directories to maintain user preferences and such, but the back-end (server application(s)), will use its own structure. A good example of a front-end application is Code Project. The front-end consists of a web server, but the user directories are used by your web browser, although the web server itself, even if considered part of the front-end, is using its own structure, because it is a server. The Code Project back-end part probably consists of database servers and other stuff I don't know about. Having this discussion with you somewhat tells me that you are fairly new to the professions. You will learn all this stuff as you go along and progress. It is a lot to learn and take years to become comfortable with all the concepts.
-
end-user: Applications allowing users, always logged in, to perform work using business applications. For instance, Word, Excel, etc. server application: Applications usually running as soon as the computer starts up, and do not need any user actually logged in. Those applications rarely sport an end-user interface (except for managing the server, but not always required). Such applications include database servers, web servers, application servers. Those applications do not follow traditional conventions because their needs are specific to them. A database server, for instance, may require to have its data disks on special disk system, shared with other database servers, for redundancy and load balancing. Server applications can also be distributed (running on multiple machines) to handle heavy load, so having user directories as their directories does not make sense. front-end: A mix of end-user and server. In this case, you have back-end systems (one more for you to learn!), consisting of server applications, and a front-end, which allows users to perform various things that will interact with the server applications to extract and store data and other business-related tasks.. A front-end application may use local user directories to maintain user preferences and such, but the back-end (server application(s)), will use its own structure. A good example of a front-end application is Code Project. The front-end consists of a web server, but the user directories are used by your web browser, although the web server itself, even if considered part of the front-end, is using its own structure, because it is a server. The Code Project back-end part probably consists of database servers and other stuff I don't know about. Having this discussion with you somewhat tells me that you are fairly new to the professions. You will learn all this stuff as you go along and progress. It is a lot to learn and take years to become comfortable with all the concepts.
Le Gauchiste wrote:
one more for you to learn!
Are you kidding me? I've been trying to remain polite despite your not answering ANY of my questions. Instead you just ignored them and tried a different angle each time. What is the point behind the two paragraphs you just wrote? Are you saying "Yes, SQL Server should default its application data folder to Program Files", or are you saying "No, SQL Server should NOT default its application data folder to Program Files"? Because that is the only point at hand. A simple "yes" or "no" would have worked a couple of posts ago but you can't seem to commit to either. I challenge you to reply with "yes" or "no". What we have here is a difference in opinion, sir. Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
-
Le Gauchiste wrote:
one more for you to learn!
Are you kidding me? I've been trying to remain polite despite your not answering ANY of my questions. Instead you just ignored them and tried a different angle each time. What is the point behind the two paragraphs you just wrote? Are you saying "Yes, SQL Server should default its application data folder to Program Files", or are you saying "No, SQL Server should NOT default its application data folder to Program Files"? Because that is the only point at hand. A simple "yes" or "no" would have worked a couple of posts ago but you can't seem to commit to either. I challenge you to reply with "yes" or "no". What we have here is a difference in opinion, sir. Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
That is because there is no yes or no. It depends on the configuration you and also company policies as for application directories. That is it. For instance, if you are developer and have a local SQL Server installation, you will probably be happy with the default installation. On other environments, like QA, staging, production, training, installations will differ. Production will certainly be the most strict regarding directory locations.
Roelof De Villiers wrote:
Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
And you are still not able to understand why SQL Server does not use user's Application Data directories?
-
That is because there is no yes or no. It depends on the configuration you and also company policies as for application directories. That is it. For instance, if you are developer and have a local SQL Server installation, you will probably be happy with the default installation. On other environments, like QA, staging, production, training, installations will differ. Production will certainly be the most strict regarding directory locations.
Roelof De Villiers wrote:
Not necessarily you being so senior and me being so junior. I am 34 and have been coding since 17. That's not exactly new to the "professions".
And you are still not able to understand why SQL Server does not use user's Application Data directories?
It's not that I don't understand. It's that I don't agree.
-
It's not that I don't understand. It's that I don't agree.
Whether you agree or not, it is how it is done.