SQL Best Practice


Author
Message
Larry Caylor
Larry Caylor
StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)StrataFrame VIP (1.2K reputation)
Group: Awaiting Activation
Posts: 592, Visits: 3.7K
In my shop we have been having a lively discussion on where to put in-house developed custom objects that access data in third-party databasesw00t The majority of the time the custom object is a view and all that's needed is read access. One side favors placing all custom objects in a separate database and accessing the target database from the custom objects DB. Their argument is that this approch simplifies the DBA's job and doesn't muck up the thrid-party DB. The other side favors placing the custom objects in the target databse making sure they are named with a prefix so they may be easily identified. Their arguments include minimizing the number of databases that must be managed and improving security since a user can easily be limited to only those objects they require. Maintenance shouldn't be a problem since the custom objects may be easily added or modified by a script that is part of the DBA's maintenance process.

I've been trying to Google something but so far haven't been able to isolate this particular issue. Has anyone else here had this discussion or care to post an opinion?

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search