Bringing Database in-house
Dear Experts,
I have been recently hired as an IT person for this company. Although my job description did not include this, I am thinking of bringing in the database that was developed by the outside consultant group in-house for better control of the application, and also for compliance.
My questions is, how difficult is it for me to master a database written in Perl, Mason, and PostgreSQL? I have a background in C++, Java, VBA programming, am familiar with Unix system, am pretty good with SQL, HTML, and have created and managed database system using MS ACCESS with VBA codes. The only experience I do not have is creating web-based application.
I am wondering, should I hire someone as a DBA, who already knows Perl and PostfreSQL, and I become a backup programmer for that person, or can I manage myself? (The reason I am wondering is I am not sure I can justify the salary of DBA at this point.)
Because this web portals for the database is the heart of my company's operation, I would not rush to get anything done, and obviously need cooperation from the consultants that are currently writing these apps.
Please advise.
I have been recently hired as an IT person for this company. Although my job description did not include this, I am thinking of bringing in the database that was developed by the outside consultant group in-house for better control of the application, and also for compliance.
My questions is, how difficult is it for me to master a database written in Perl, Mason, and PostgreSQL? I have a background in C++, Java, VBA programming, am familiar with Unix system, am pretty good with SQL, HTML, and have created and managed database system using MS ACCESS with VBA codes. The only experience I do not have is creating web-based application.
I am wondering, should I hire someone as a DBA, who already knows Perl and PostfreSQL, and I become a backup programmer for that person, or can I manage myself? (The reason I am wondering is I am not sure I can justify the salary of DBA at this point.)
Because this web portals for the database is the heart of my company's operation, I would not rush to get anything done, and obviously need cooperation from the consultants that are currently writing these apps.
Please advise.
Who is Participating?
I also wanted to add, I have been reading about Perl, and hear some opinions calling it becoming outdated. Am I better off porting this into Windows-base server and Microsoft VBA based system? Not sure what would be the best choice, clearly I need guidance, please.
I'm totally in favor of bringing technology in-house when possible. The answer, as your question implied, is much more than "can we do it".
First off, the programming language used by the application is not so important. That's an application/framework question. The database is a platform unto itself, and most of the popular languages (perl included) have APIs for all the popular databases.
Second, "mastering" a database is an evasive question. You have the database platform, e.g., MySQL, PostgreSQL, or MSSQL, and you have the database schema created within that platform. Your background with MSAccess will have exposed to you SQL, albeit Access' bastardized version of it, but you need to realize that Access is very far from being an adequate database platform. The other platforms I mentioned are a much bigger world, with much more to learn and implement. Moving to a "big-boy" platform is much like moving to the NFL after playing tag football with your friends. The good news is that PostgreSQL has documentation that will hold your hand as much as you need it to.
The other part of "mastering" the database is the schema. Knowing the platform and the language is great, but understand the implementation is critical. You need to be able to explore and understand the tables, view, and stored procedures. This is generally dependent on two items: your ability to visualize abstract concepts and structures, and the original author's ability to intuitively design the structure. If the designer did anything "special", then you have additional parts of the puzzle to dissect to have a true understanding of the mechanics.
In the end, you are the only person who can answer this question. I recommend taking some time to learn the database, and how it operates within the context of your application. Take advantage of the support you currently have for it - if you submit a trouble-ticket, ask that they explain the issue when it is resolved. I highly recommend understanding the database before doing any kind of migration.
First off, the programming language used by the application is not so important. That's an application/framework question. The database is a platform unto itself, and most of the popular languages (perl included) have APIs for all the popular databases.
Second, "mastering" a database is an evasive question. You have the database platform, e.g., MySQL, PostgreSQL, or MSSQL, and you have the database schema created within that platform. Your background with MSAccess will have exposed to you SQL, albeit Access' bastardized version of it, but you need to realize that Access is very far from being an adequate database platform. The other platforms I mentioned are a much bigger world, with much more to learn and implement. Moving to a "big-boy" platform is much like moving to the NFL after playing tag football with your friends. The good news is that PostgreSQL has documentation that will hold your hand as much as you need it to.
The other part of "mastering" the database is the schema. Knowing the platform and the language is great, but understand the implementation is critical. You need to be able to explore and understand the tables, view, and stored procedures. This is generally dependent on two items: your ability to visualize abstract concepts and structures, and the original author's ability to intuitively design the structure. If the designer did anything "special", then you have additional parts of the puzzle to dissect to have a true understanding of the mechanics.
In the end, you are the only person who can answer this question. I recommend taking some time to learn the database, and how it operates within the context of your application. Take advantage of the support you currently have for it - if you submit a trouble-ticket, ask that they explain the issue when it is resolved. I highly recommend understanding the database before doing any kind of migration.
Dear routine,
Thank you for your thoughtful comment, and yes, you are right. It is ultimately myself that must decide this. I think I already know that the database must be brought in-house. I think I am just looking for any pitfalls I must prepare for.
I forgot to mention that I used to teach MySQL so I am exposed to SQL not only from MS Access.
After reading your comment, it is clear that I must understand the database schema, which I think I can.
I was wondering if any Experts had a similar experience, in which you must bring some application that does not allow any down-time into the organization and take over the management/development. I would imagine that this becomes almost political, because the consulting company does not want to let it go, and I may find it difficult to have their full support. That is why I was wondering if I should hire someone already versed in the languages it was written in.
Any input is appreciated, thank you!
Thank you for your thoughtful comment, and yes, you are right. It is ultimately myself that must decide this. I think I already know that the database must be brought in-house. I think I am just looking for any pitfalls I must prepare for.
I forgot to mention that I used to teach MySQL so I am exposed to SQL not only from MS Access.
After reading your comment, it is clear that I must understand the database schema, which I think I can.
I was wondering if any Experts had a similar experience, in which you must bring some application that does not allow any down-time into the organization and take over the management/development. I would imagine that this becomes almost political, because the consulting company does not want to let it go, and I may find it difficult to have their full support. That is why I was wondering if I should hire someone already versed in the languages it was written in.
Any input is appreciated, thank you!
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month4 days, 14 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
I've had plenty of experience with exactly these kinds of scenarios. When I worked in hosting, it was an almost-everyday occurrence that a customer needed a database moved either to, from, or within my company. It is always more painful when you do not have the full support of the hosting company, but their cooperation is only necessary to the extent that you need full access to the database. That access can come as shell access into the server or maybe just access to a point-in-time backup that you can trigger.
The process I've always followed:
1) set up a working sandbox copy of the application. It should point to a working copy of the existing database, preferably on the existing server. You want your starting environment to be as close as possible to your production environment.
2) Attempt to copy the database to your new platform, also a sandbox. This means getting a point-in-time backup of the current database, restoring it into the new environment, and verifying its responsiveness.
3) Change your sandbox application to hit the database copy.
If you can successfully complete those three steps, then you know you can safely migrate with very little interruption. Document the process thoroughly, and test it even more so. If done properly, the only downtime you'll need to experience is the final backup/restore.