Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-03-08 : 09:56:25
|
| rangagurucholan writes "right now i have used stored proc in my project. my problem is the tables created are dynamic depending on the client. for example, let say if a company X registers in our site for using our ASP, a set of tables with an prefix as that of the company will be created. in the above case the table starts with a prefix x. right now i have used stored proc for database manipulation. since the tables are going to be generated depending upon the company, i need to created a set of stored proc for this comp. eg. the stored proc name start with x_stored_proc. for 'X' company. my question is, 1.is it possible to create dynamic stored proc. 2.is it right what im doing, because maintainance might be of big problem. do provide me a solution.thank youcholan" |
|
|
Jay99
468 Posts |
Posted - 2002-03-08 : 10:19:36
|
quote:
do provide me a solution
Easy there big fella . . . asking for help is one thing, demanding solutions will very quickly result in a thread boycott . . .quote:
...let say if a company X registers in our site for using our ASP, a set of tables with an prefix as that of the company will be created...2.is it right what im doing, because maintainance might be of big problem....
Sounds to me like a big maintenance problem. Create one set of tables with a CompanyID or some other appropriate foreign key to a RegisteredCompanies table.Jay |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-03-08 : 11:42:05
|
| I totally agree with Jay about this, you are going to have a nightmare pretty quickly with your current setup.If the procedures are the same for each company, there's absolutely zero benefit in copying the same tables, procedures, etc. for each company. All company information should be kept in a single table, and the stored procedure would accept a parameter that identifies which company should be processed.If security considerations prevent this, then each company's information should be kept in a separate database. Also not efficient, but far easier to manage than what you suggest. Using prefixes to segregate objects is not a good idea either, it only causes unnecessary confusion.It's hard for us to say what would be a better solution without more detailed information on what you're doing...what the tables are for, what information they stored, what the processes and procedures need to do, etc. If you can provide table structures and an explanation of what you need to accomplish, it will help us help you better. Again, we need to know WHAT you want to do, not HOW you want to do it. |
|
|
|
|
|
|
|
|
stored proc - dynamic