1

I have several customers, each running a customized version of my ISQL (SE) desktop app. I would like to replace their desktop app with thin client WinTerm's, connecting to the cloud (My ISQL app on an SuSE Open or RedHat server). If this can be done, I would like for each customer to use one standardized version of my app to simplify updates and support. However, I'm not sure what's the best way to design the database. Should each customer have their own database.dbs (DBPATH=) or is there a better design?

Joe R.
  • 2,032
  • 4
  • 36
  • 72

1 Answers1

1

You have two options, one of them that you've already considered:

  1. Each customer has their own database with the standard name.
  2. Each customer has their own database with a separate name for each.

The advantage of option 1 is that your existing code would work substantially unchanged; you'd simply have to ensure that the setting of DBPATH is correct for each customer. The downside is that you need to create a separate directory for each customer too. However, this has its merits; you can probably more easily keep Customer A from seeing any of the files generated by Customer B (and vice versa) if each customer has their own separate home directory, and their database is located in that directory.

The advantage of option 2 is that you can put all the customers' databases in a single directory. As mentioned, this is apt to make it easier for Customer A to see stuff that he should not see that belongs to Customer B. You would also have to ensure that you override the default database name every time you run a command - whether that's sperform or sacego or anything else.

Between the two, I would go with option 1 (separate databases with common name in different directories), with rigid walls between customers. Each customer would have their own user name and group, and the permissions on the directories would avoid public access of any sort. They can all still use a single INFORMIXDIR and your associated forms and reports.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • I agree with your choice of option 1. I want to make as little changes possible to my apps source code, thus all users will be sharing the same code and INFORMIXDIR. My app has a hefty control table which will allow each customer a decent level for customizing the way the system functions. As you may already know, my apps topography has an average of 7,000 customer rows and avg. of 10,000 related transaction rows. Since local laws require my customers to retain 5 years transaction history, that table will not grow beyond 10K rows.. At which point should I consider using IDS? – Joe R. Jun 24 '11 at 04:19
  • @Frank: that should probably be a separate question, but... Although SE is certainly capable of handling the data volumes you describe, you could consider IDS at any time. You would, however, want to run with Option 2 in this question; you would not create an entire IDS instance for each customer, but each customer would have their own separately named database in the IDS server. If you get to a few hundred customers, you probably should think about using IDS, though I've heard of (big) machines running 1500 concurrent users on SE. – Jonathan Leffler Jun 24 '11 at 04:24
  • OK, I can start out with SE and if need be, change to IDS. So if I implement option 1, where each customer site has their own chmod 700 directory, will those permissions be sufficient to prevent wandering users or will it be necessary for them to login under a restricted shell (rsh)? – Joe R. Jun 24 '11 at 04:49
  • @Frank: 700 will stop them wondering around into each other's territory, and I believe it will do so without preventing SE from gaining access to the database. – Jonathan Leffler Jun 24 '11 at 05:11