While designing this database, I came across
a number of problems: poor indexing and drawing a single table for all domain
values. The Payment section was difficult to develop as I did not know how to
index it properly and correctly. There are times when an application or user
needs to query several columns of a table. As the number of rows was recorded,
the table grew significantly and this impacted the time queries took to
complete. To speed up the process and to reduce the effect of overall table
size, I had to spend extra time in indexing the table columns, and this helped
me make the entries visible instantly. For this purpose, I have to invoke a
SELECT query, which sometimes leads to deterioration of the INSERT, UPDATE and
DELETE commands. The indexes were to synchronize to the content of the
database. The problem was finally solved by having a single index for all
columns, and this was distinct from the main key I used to query the table.
Another significant problem was that an
all-encompassing domain table did not prove to be as beneficial as I expected
it to be for the database design. In the Bill section, it took me a lot of time
and energy to mention the number of the bill, date of the bill and status of
the bill. It should be noticed that a relational database is built around the
idea that every object in the database will represent one thing only. As part
of the normalization process, the breaking down and isolation of data ended in
every row which represented a single thing.
While modeling or mapping the schema, I found
it difficult to store or maintain data. When I used the code that could help
access the database, it took me a lot of time to store and maintain the data
(Elmasri, 2018). At this point, I felt that it was good to get a programmer
involved. The stored procedures provide us with the power to change features of
the database code without the involvement of additional resources. Finally, I
was able to make small changes and a couple of major upgrades (such as changes
in the SQL syntax) in order to ease my work.
Based on the requirements of the project and
the database schema, the first hosting option is HostGator. It is known to
provide shared, virtual private server, reseller and dedicated web hosting
services. Another ideal option is Bluehost, which is a reputed web hosting
company by Endurance International Group. Bluehost operates all of its servers
in-house, which means quality is always guaranteed. One of the major advantages
of this hosting service is that its servers are powered by HTTP/2, NGINX+
caching and PHP7 (Halpin et al. 2003).
An SQL Server with up to three terabyte data storage capacity is
required to store the five-year-old history of the data. This will be loaded
from the new internal data warehouse and the historical pharmacy uploads. The
estimated budget for the server is $25,000 USD, and nearly $ 60,000 will be spent on other things.
The one limitation of the current data
warehouse is that it will be used to load the proposed data structure, with
focus on historical data only. I think that this could be improved by focusing
both on the latest and historical information. As far as the design is
concerned, I think that it is an innovative design and will help store patient
data in a better way.
References
Sabo, A. (n.d.). Retrieved
from
https://www.gcumedia.com/digital-resources/cengage/2018/database-systems_design-implementation-and-management_13e.php
Halpin, T., Evans, K.,
Hallock, P., & Maclean, B. (2003). Generating a Physical Database Schema. Database
Modeling, 231-253. doi:10.1016/b978-155860919-8/50015-1
Elmasri, R. (2018). Database
Schema. Encyclopedia of Database Systems, 973-974.
doi:10.1007/978-1-4614-8265-9_80735
Raflik, M., & Pätzold, B.
(1990). Database Schema Definition. CAD*I Database, 101-121.
doi:10.1007/978-3-642-84335-8_5
Database Schema Integration.
(n.d.). SpringerReference. doi:10.1007/springerreference_61915
