Danzy83 wrote:
n the design, data will be accessed by medical institutions so I have to consider connections to the server in advance.
That is a business requirement not an implementation requirement. So exactly what do you think is going to be connecting to your database? And did you actually attempt to size this? How many requests will your product generate? How long will it take to process them? How many users will be using it? What is the expected sustained rate? What is the burst rate? If a request took 1 second and was made once an hour then you could handle 10,800,000 requests without reconfiguring anything on the database server. There are less than 6,000 hospitals in the US. There are less than 200,000 medical clinics. How many of those are there in your market? At least where I am selling into medical concerns is significantly difficult, even for institutions that have money. Many institutions operate on tight budgets. So expecting to own the entire market is highly unrealistic. (And yes I have worked on products in the medical industry.) So what is your real expected market share? What is your realistic expected growth rate? And this of course completely ignores how these places are going to connect to you. The "internet" means that you are going to expose your database directly to the internet. Which is a bad idea and I suspect (hope) that institutions would refuse to do business with that arrangement. Most performance problems occur due to architecture and design problems. Not technological problems. Attempting to solve serious performance problems with technology is likely to fail because technology only allows for incremental impacts on performance. And this of course presumes you use the technology right in the first place.
