I work with a group of developers that insist their application's success depends on being able to create databases and tables on the fly. Their proposed naming convention is databases (job number) and for tables (job number "_" order number. I tried to explain this plan eludes any "normal" notion of database sanctity or sanity and giving out DDL Admin rights to a .Net component is a bad idea, all to no avail. Anyone out there with an opinion either way or am I taking my title (DBA) too seriously?To create databases and tables on the fly !!!!
Good idea! But who will be in charge for supporting this?
DBA or Developer? I guess anyone knows answer. On fly it is possible to create 'temporary' permanent objects - and remove them by using some rules. Use script for creating DB from application.|||It sounds to me like your developers don't understand the concept of scalability, or they wouldn't need to be creating database on the fly for different job numbers, or different tables for different orders. It sounds absurd, and rather amateur to me (you asked for opinions, right?).
Another 1 or 2 dimensions in their tables would handle it.
blindman|||Sounds like you just caught the SharePoint Team Services bug. Microsoft brags about a server with over 1,000 databases on it. Just tell the developers (and management) that you can not really be responsible for the performance on this machine, since you can not predict disk usage, or reallocate any files anywhere about, because they just keep coming back. If you have one disk fill up, then all you will get is errors from your application. God help you, if you catch a runaway transaction that blows your transaction logs beyond the bounds of normal space, too.
Just remember, just because Microsoft tells you you can do something, doesn't mean you should do it.|||Sound like MCrowley already "been there, done that" like I am in deep
caca with Sharepoint right now. They created DB "on the fly" like rabbit running high on Viagra... The DATA & LOG files default setup in the SQL Server's Properties won't apply to these Sharepoint DB creation (only effective when using GUI to create DB) . The only concept of scalability they can understand is getting higher & higher... :-)|||Sounds to me that your developers just re-invented the concept of partioned tables; however, not really clever. Temporary databases should not the way to do it! Could you get some more deeper into details of your developer's intentions? I'm sure we all here can propose much more cleverer ways to achieve the same.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment