Timeline for Getting the "flat" query corresponding to a view using nested views?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2021 at 16:59 | history | edited | J.D. | CC BY-SA 4.0 |
added 395 characters in body
|
| Jan 13, 2021 at 16:55 | comment | added | J.D. | ...product works off of a single centralized SAP instance (I'm not sure if this is possible, as I haven't personally used SAP), then you may be able to get away with only replicating that one instance for all your customers. It really depends on what the current setup is, and how your product gatekeeps between SAP and your clients. If your case is the former (multiple SAP instances, one per client) then you still have the ability to replicate all of those instances data into one centralized database that your product can access and gatekeep to the clients appropriately, to minimize costs. | |
| Jan 13, 2021 at 16:53 | comment | added | J.D. | @TaylanKammer Sorry I didn't gather from your original post that you were selling services to other clients with your own schema on top of SAP's effectively making you the middleman (I assumed your end users were internal). Could you elaborate on the SAP component of it?...does every client of yours get their own SAP database? If so, in order to keep your product scalable and better future proof, you may need to bite the bullet of replicating the data outside of SAP so you have better control, and unfortunately roll that into the costs to your clients (just as SAP is). If somehow your... | |
| Jan 13, 2021 at 16:46 | comment | added | TaylanKammer | Well, someone has to host the additional database. The customer is not going to do it, otherwise they would have chosen an on-premise deployment in the first place. We don't have the infrastructure to do it for all customers who buy our application internationally. It could be off-loaded to third parties; not sure what that would cost, but it would break the simplistic deployment model of the application. It's kind of "plug-and-play": install the app, configure the connection to your SAP Business One cloud account (API URL, username, password), and start using it. That's a big selling point. | |
| Jan 13, 2021 at 14:11 | comment | added | J.D. | ...how it would "incur an unreasonable per-customer cost"?...if you're thinking because additional licensing to SAP would be warranted that's untrue. Synchronizing the SAP source database outside their system to another destination is outside the scope of SAP at that point & outside the licensing requirements. If they were able to enforce licensing for doing so the same would be true for every backup you take, or something as stupid as copy some data out of the database and sending it in an email for business purposes. Otherwise, I'm not sure what other "per-customer" cost you're referring to. | |
| Jan 13, 2021 at 14:08 | comment | added | J.D. | @TaylanKammer I do understand it seems roundabout to have to "copy" the database to a second database but this is quite common of a solution when you are limited on access to the source database (usually moreso due to avoiding breaking the warranty included with such system, and centralizing multiple systems into one database). It's something I've done for other ERP and CRM systems (cloud or on-prem - didn't matter) in the past, since unfortunately when you're limited to access of the database by the vendor then you're limited on the solutions around that as well. I'm not sure I follow... | |
| Jan 13, 2021 at 5:23 | comment | added | TaylanKammer | Interesting ideas. Unfortunately in our case both are rather unrealistic. The deployment I'm speaking of where I lose the ability to create views is "cloud"-based deployment where customers don't get access to the DB server at all, and the only way to execute queries (in a strict subset of SQL) is through a REST API. Synchronizing the data to another DB we have control over would incur an unreasonable per-customer cost and kind of defeat the purpose of that deployment type. The app I'm developing is meant as a "mass market" and "plug and play" type of solution for these deployments. | |
| Jan 12, 2021 at 1:45 | history | answered | J.D. | CC BY-SA 4.0 |