Any updates to this view are then passed through this layer via update commands.
Either you are expressing it incorrectly or there is no layer.
You said you used the "view" in the "control".
If instead you are using a DTO in the "control" then that is not the same as what you said.
If however you are using a language specific layer to access the a view in the control then there is no database layer.
So I am still not getting what is wrong with using the results of a view in a GUI.
First, the question, per the OP, is why someone would insist that only views be used. It isn't whether views might or might not be used.
Second, as I already said your terminology/phrasing is not precise. If you have a database layer then you are not using the view in the GUI. What you are using is the results of the database layer or even business layer in the GUI. The fact that they originated from a view in another layer is irrelevant and expressing it that way should be avoided because data model entity might not originate in a one to one mapping with the database. And the user (GUI) should not concern itself with how it did originate from he database.
I ran across this attitude in the 90s (and not since) I believe it was based on security, there was a difference between table and view security back then. I would be very interested in your DBAs reasoning behind the statement.
You can insert into views if there is 1 table in the view (how dumb is that) or the relationships are not too complex. I have never explored this as I also think it is a horror waiting to happen.
Never underestimate the power of human stupidity
At that time I was using Oracle (6) and I remember asking the DBAs why the views (there weren't many) had an _v suffix and the response was "to remind the developers that they are views and therefore readonly".
Because some companies are quite divided.
The right place to do it is in the application, but I've been working for companies where the database department were responsible for that one department couldn't see the same columns as another department.
It's a lot easier to keep track on this with a view than with column permissions.
When it comes to licensing it doesn't matter. It's the number of actual users that counts, not the number of users you setup in the database. It's a common misconception.
"The ones who care enough to do it right care too much to compromise."
f you want to filter the contents of a table for a certain group of users
Sure but that is one of the uses of a view - a very old fashioned use, but still valid. Who puts authorisation logic at that level these days. Apps no longer have to rely on the database for authorisation, very 80s
Never underestimate the power of human stupidity
The db I am testing is locked ATM doing some data-loads so I can't get various potential methods of doing this so I figured I would ask. I have a database with each table having its own file group and each file group has one file. Is there a simple method (other than Import Data and Bulk insert type operations) to detach the file groups (ok, maybe not detach they will be read-only) and copy the table, file group, and file into another database on a completely different server.
My thought would be to just copy the physical files and then through some magical T-SQL have the files appear as the new table. I believe in My-SQL copying db files is all that is required but SQL Server is a special lady. Any thoughts? I am only dealing with about 60 million records an hour so not that much data.
Is there a simple method (other than Import Data and Bulk insert type operations) to detach the file groups (ok, maybe not detach they will be read-only) and copy the table, file group, and file into another database on a completely different server.
Thanks for your reply, unfortunately, your method requires that the other database have the tables and files and file groups already created and requires the DB to be taken offline in order to add the new files and file groups which contain the table data.
What I am looking for is some black magic to take files from a separate database and bring then into a different database without bringing it offline. Assuming both databases have the exact same configuration, this is technically possible (otherwise you couldn't add new files and file groups while SQL Server is running) but it is likely a dark-art. Bringing the database offline is not a valid solution for me needs.
your method requires that the other database have the tables and files and file groups already created and requires the DB to be taken offline in order to add the new files and file groups which contain the table data.
Not necessarily so; you can attach it under a different name to the same server. Next, you SELECT INTO the tables from Database1.Dbo.TableName to Database2.Dbo.TableName
Ennis Ray Lynch, Jr. wrote:
What I am looking for is some black magic
Aight, sacrifice a chicken and a donkey at the next full moon. More seriously; if you have access to a DBA, ask him/her how they'd implement horizontal partitioning. You could do something similar on a more simpeler level; you'd have to change your select-query to dynamically check for new databases, and to union it along. Could be done by querying sys.databases and building the select/union from that.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]