Your advice for finding a new databse guru, please...
July 30, 2010 3:56 PM Subscribe
I need to find a new database guy/gal. Where do I look and how will I know when I've found a good one?
Things that may help you point me in the right direction: We're a Windows shop. The database in question is in MS Access. There's around 150,000 records. I'd prefer to stay with Access, but I'd consider changing (all depends on the cost/complexity). I'm looking after becoming more than a little dissatisfied with my current dev team.
So, how do I go about finding a new developer friend?
Things that may help you point me in the right direction: We're a Windows shop. The database in question is in MS Access. There's around 150,000 records. I'd prefer to stay with Access, but I'd consider changing (all depends on the cost/complexity). I'm looking after becoming more than a little dissatisfied with my current dev team.
So, how do I go about finding a new developer friend?
TPAA is more than correct. Access gets a little unwieldly after ~25000 records in my experience. Good thing about it is that if you're using a Visual Basic app or something similar to access this DB, then it'll take a little maintenace but most things should work the same. If not, you'll need someone that can do light application/web development using SQL Server to develop a front end to go with the new back end. Look for someone that can do both types of development, and do them semi well. How you grade 'well' is of your own opinion, but reach out to people you know outside the company but in the industry, to get feedback. Personally, I'd look for someone with a couple of years experience in both SQL Server and a Microsoft programming language of your choosing (VB, VC#, ASP.Net if you want to do web based things)
posted by deezil at 4:17 PM on July 30, 2010
posted by deezil at 4:17 PM on July 30, 2010
Seconding These Premises about reluctance to support a large Access database.
If you're not technical enough to handle it yourself, then you really don't have the needed skills to evaluate a DBA and tell whether or not she's great, competent, or a loser. What you need is a referral from a developer whose opinion you trust.
How are you dissatisfied with your current dev team? Do they not seem competent, or are they not responsive enough? Is the DBA part and parcel of the team, or can you complain to one of them that they need to find a new DBA?
If you need to replace the team, then it's time to hunt around for referrals from unrelated developers. Typically you would start with a web guy--website builders usually know at least a few backend developers who know databases, and have some work history with them to judge by.
posted by fatbird at 4:21 PM on July 30, 2010
If you're not technical enough to handle it yourself, then you really don't have the needed skills to evaluate a DBA and tell whether or not she's great, competent, or a loser. What you need is a referral from a developer whose opinion you trust.
How are you dissatisfied with your current dev team? Do they not seem competent, or are they not responsive enough? Is the DBA part and parcel of the team, or can you complain to one of them that they need to find a new DBA?
If you need to replace the team, then it's time to hunt around for referrals from unrelated developers. Typically you would start with a web guy--website builders usually know at least a few backend developers who know databases, and have some work history with them to judge by.
posted by fatbird at 4:21 PM on July 30, 2010
Yeah, you're probably going to want to shift the database to SQL server, especially if you anticipate any kind of growth.
If you have an Access frontend with forms/workflow you use to (ahem) access the data, you can pretty painlessly continue to use that by setting up an ODBC connection to the new SQL server and continue to use the frontend.
As far as good DBAs go, I don't know how much help I can be. Look for general problem solving skills and experience, as SQL is very easy, it's more understanding the client's (or your own businesses') business practices and requests and transforming that into the storage schema, knowing when to trade storage space for increased speed, etc that you pay these guys for.
posted by spatula at 5:28 PM on July 30, 2010
If you have an Access frontend with forms/workflow you use to (ahem) access the data, you can pretty painlessly continue to use that by setting up an ODBC connection to the new SQL server and continue to use the frontend.
As far as good DBAs go, I don't know how much help I can be. Look for general problem solving skills and experience, as SQL is very easy, it's more understanding the client's (or your own businesses') business practices and requests and transforming that into the storage schema, knowing when to trade storage space for increased speed, etc that you pay these guys for.
posted by spatula at 5:28 PM on July 30, 2010
What These Premises Are Alarmed said.
I'm going to put it bluntly: Access sucks and whatever problems you have are almost certainly traceable directly to the choice of Access as database. It is completely unsuitable for anything more complex than the Ladies Sewing Circle Auxiliary Membership Database. No professional database application developer worth his salt would ever use Access unless the only other choice was Excel. Ask your team what they'd rather use. If they're at all competent they'll jump at the chance to switch to something that's actually sane to run a 150,000 row line-of-business production application on. If they don't jump at the chance, you'll have your answer as to their competence and can shuffle them out the door.
You don't have to pay through the nose for SQLServer. PostgreSQL is free and available for Windows. Migrating to a real database is going to cost money and it probably won't be as simple as you'd like. There will be the inevitable data type conversion issues and other problems that crop up in conversions like these. It will take more time and money than anybody expected, even if you take into account Hofstadter's Law.
As for evaluating development outfits, you can't just look for the Programmer's Virtues. About the only way that's worth doing is asking for references. Good ones will have people you can call on the phone and talk to that will tell you how happy they are with the work that was done. Try to talk to actual users or the the person that actually signed off on the bill. CIOs and IT departments are rarely in love with outfits that get brought in by management to get things that the department can't or won't do done. (Take it from somebody who gets brought in by management to finish the projects the IT department said they can't or won't do.)
Keep in mind that good outfits won't be cheap, and cheap outfits won't be good.
posted by ob1quixote at 5:33 PM on July 30, 2010 [3 favorites]
I'm going to put it bluntly: Access sucks and whatever problems you have are almost certainly traceable directly to the choice of Access as database. It is completely unsuitable for anything more complex than the Ladies Sewing Circle Auxiliary Membership Database. No professional database application developer worth his salt would ever use Access unless the only other choice was Excel. Ask your team what they'd rather use. If they're at all competent they'll jump at the chance to switch to something that's actually sane to run a 150,000 row line-of-business production application on. If they don't jump at the chance, you'll have your answer as to their competence and can shuffle them out the door.
You don't have to pay through the nose for SQLServer. PostgreSQL is free and available for Windows. Migrating to a real database is going to cost money and it probably won't be as simple as you'd like. There will be the inevitable data type conversion issues and other problems that crop up in conversions like these. It will take more time and money than anybody expected, even if you take into account Hofstadter's Law.
As for evaluating development outfits, you can't just look for the Programmer's Virtues. About the only way that's worth doing is asking for references. Good ones will have people you can call on the phone and talk to that will tell you how happy they are with the work that was done. Try to talk to actual users or the the person that actually signed off on the bill. CIOs and IT departments are rarely in love with outfits that get brought in by management to get things that the department can't or won't do done. (Take it from somebody who gets brought in by management to finish the projects the IT department said they can't or won't do.)
Keep in mind that good outfits won't be cheap, and cheap outfits won't be good.
posted by ob1quixote at 5:33 PM on July 30, 2010 [3 favorites]
I get found a lot via LinkedIn, believe it or not. Ask your friends if they know any microsoft geeks.
SQL Server Express 2008 R2 is free for recordsets up to 10GB, I think. You miss out on some features, but it'll be much more stable than Access.
posted by SpecialK at 9:47 PM on July 30, 2010
SQL Server Express 2008 R2 is free for recordsets up to 10GB, I think. You miss out on some features, but it'll be much more stable than Access.
posted by SpecialK at 9:47 PM on July 30, 2010
Keep in mind that good outfits won't be cheap, and cheap outfits won't be good.Actually, the triangle is good/cheap/fast, pick any two. For instance, I'm good, and I'm cheap, but I am certainly not fast because I have a limited number of evening and weekend hours to work in.
posted by SpecialK at 10:19 PM on July 30, 2010
No professional database application developer worth his salt would ever use Access unless the only other choice was Excel.
I can envision scenarios where 150,000 rows in Access is viable. So I wouldn't immediately slam the door on a developer who would consider this, if they come highly recommended from a credible source and can prove past successes with similar projects.
posted by okbye at 10:24 PM on July 30, 2010
I can envision scenarios where 150,000 rows in Access is viable. So I wouldn't immediately slam the door on a developer who would consider this, if they come highly recommended from a credible source and can prove past successes with similar projects.
posted by okbye at 10:24 PM on July 30, 2010
Just as an anecdote; I've had issues with access databases in a database that had probably less than 10,000 records spread across a dozen or so tables. This was several years ago, but as I remember it, the problems usually occurred when multiple users were accessing the website simultaneously.
If you're considering changing databases, MySQL is a free option. I think it should still play will with your "windows shop" environment.
posted by Sonic_Molson at 11:02 PM on July 30, 2010
If you're considering changing databases, MySQL is a free option. I think it should still play will with your "windows shop" environment.
posted by Sonic_Molson at 11:02 PM on July 30, 2010
Seconding everything above, and adding this: "DBA" has always been a vague title, as it's used both for a) people who know a whole lot about setting up the database server and administering it and for b) people who know a lot about database design and for c) people who know a lot about SQL optimization and indices and how to write views/sprocs/whatever in the particular SQL dialect of a particular RDBMS.
(E.g., I do b and c and a tiny bit of a, but in support of particular applications rather than in support of a database server that supports multiple applications.)
So, we need to know what you want this DBA to do: maintain/admin your existing database, or build new ones, because these are very different types of roles, suited to very different temperaments.
posted by orthogonality at 11:20 PM on July 30, 2010
(E.g., I do b and c and a tiny bit of a, but in support of particular applications rather than in support of a database server that supports multiple applications.)
So, we need to know what you want this DBA to do: maintain/admin your existing database, or build new ones, because these are very different types of roles, suited to very different temperaments.
posted by orthogonality at 11:20 PM on July 30, 2010
scroll up to the very top of this page...see where it says 'jobs'? click that.
posted by sexyrobot at 11:39 PM on July 30, 2010
posted by sexyrobot at 11:39 PM on July 30, 2010
To orthagonality's point, I'd say no- that describes an entry level DBA or db developer.
Anyone pitching their services as a DBA had better know a,b, and c- and be able to do it across database platforms.
To the OP, you're going to have a lot of difficulty finding anyone competent to work with Access. That's just the product's reputation (and I confirm that it deserves its reputation.)
My first suggestion would be to use the SQL Import functionality in the newer versions of Access and get that into SQL Server. That single move will expand the number of potential DBA's tenfold.
Other than that, I'd use the standard tools. Dice, Monster, LinkedIn. Pitch a job at SQLServerCentral.com.
I'd strongly recommend group interviews and practical questions. As alluded to with orthagonality's point- there's a lot of folks who spend one year working with .NET db objects and start pitching themselves as DBA's, as the billing rate is so much higher.
posted by mrdaneri at 7:20 AM on July 31, 2010
Anyone pitching their services as a DBA had better know a,b, and c- and be able to do it across database platforms.
To the OP, you're going to have a lot of difficulty finding anyone competent to work with Access. That's just the product's reputation (and I confirm that it deserves its reputation.)
My first suggestion would be to use the SQL Import functionality in the newer versions of Access and get that into SQL Server. That single move will expand the number of potential DBA's tenfold.
Other than that, I'd use the standard tools. Dice, Monster, LinkedIn. Pitch a job at SQLServerCentral.com.
I'd strongly recommend group interviews and practical questions. As alluded to with orthagonality's point- there's a lot of folks who spend one year working with .NET db objects and start pitching themselves as DBA's, as the billing rate is so much higher.
posted by mrdaneri at 7:20 AM on July 31, 2010
Since the current system seems to be an access app with access database , I don't think the op is looking for a DBA but rather an app developer but he would need to clarify that.
posted by canoehead at 10:13 AM on July 31, 2010
posted by canoehead at 10:13 AM on July 31, 2010
Response by poster: Ahhh. Back from the weekend and ready to delve into this again. Here are some thoughts/answers to some points that came up (if anyone is still reading this):
My current team (there's two of them) are Access developers. Access is, as far as I know, their go-to DBMS/ the only thing they work with. When I asked two years ago if we were reaching the point where it would make sense to migrate to something... other than Access, I was told that we still had a long way to go with Access. Our back end weighs in at 75MB and the largest Access can get is 2 gigs (right?), so I guess they're right in a way. I think that one of them batted around the idea of a SQL back-end with an Access front, but it was coached in terms of being in the far, far, future.
A little history: I work for a membership based non-profit. Our membership roll is kept on the database in question. We have a tiny staff (3). I'm the one that gets to handle/make the decisions about the tech stuff (after I argue and plead with my boss). I'm at best a gifted amateur, but I learn quickly. Elliott and Steve are our DB guys. Elliott owns his own company and Steve is his employee. When my organization decided to brave the world of electronic records (in the 80's) it hired Elliott right out of college to design a database and provide DB administration on a per instance basis. The DB didn't initially go into Access, but it was brought into Access by Elliott. Elliott (and then Steve) are the only two people who have ever done any work on the DB. Two years ago, our organization went through a major change. We needed a new database developed. We, of course, went to Elliott and Steve who developed one in Access. It's a pretty snappy database and we're mostly very happy with it. It cost between $20-30,000. We're looking to have some work done on it sometime this year.
This past week, our membership database went buggy. I called Steve (I very rarely talk to Elliott). I ended up... less than pleased. A minimum number of records (around 20) got messed up. Steve basically blamed me for it. The explanation he gave didn't ring true with me. Basically, Steve says that I did something which altered the primary key on one of the tables in the database. After I got off the phone with him, I checked the back-up versions of the same database. NONE of the tables have ever had a primary key that I can see. I get the distinct impression that someone is pissing on my boot and telling me that it's raining.
I'm going to pay Elliott and Steve to put this table back to rights, but I've become very leery of handing over $5-10,000 or more on re-development of our second database when my faith in their abilities has significantly diminished.
I'm not dedicated to Access. If moving out of it will solve more problems than it causes, I'm all for it. I'm leaning in that direction. I'm willing to invest time and effort in learning how to work with a new developer (if that's what I'm asking for). The organization isn't big (rich) enough to support an on-call database administrator, so most of the day to day stuff falls to me. It would be helpful to work with someone who understands this and doesn't dismiss me with "it's much to complicated for you to understand."
Any other advice or notes?
posted by Vavuzi at 2:27 PM on August 2, 2010
My current team (there's two of them) are Access developers. Access is, as far as I know, their go-to DBMS/ the only thing they work with. When I asked two years ago if we were reaching the point where it would make sense to migrate to something... other than Access, I was told that we still had a long way to go with Access. Our back end weighs in at 75MB and the largest Access can get is 2 gigs (right?), so I guess they're right in a way. I think that one of them batted around the idea of a SQL back-end with an Access front, but it was coached in terms of being in the far, far, future.
A little history: I work for a membership based non-profit. Our membership roll is kept on the database in question. We have a tiny staff (3). I'm the one that gets to handle/make the decisions about the tech stuff (after I argue and plead with my boss). I'm at best a gifted amateur, but I learn quickly. Elliott and Steve are our DB guys. Elliott owns his own company and Steve is his employee. When my organization decided to brave the world of electronic records (in the 80's) it hired Elliott right out of college to design a database and provide DB administration on a per instance basis. The DB didn't initially go into Access, but it was brought into Access by Elliott. Elliott (and then Steve) are the only two people who have ever done any work on the DB. Two years ago, our organization went through a major change. We needed a new database developed. We, of course, went to Elliott and Steve who developed one in Access. It's a pretty snappy database and we're mostly very happy with it. It cost between $20-30,000. We're looking to have some work done on it sometime this year.
This past week, our membership database went buggy. I called Steve (I very rarely talk to Elliott). I ended up... less than pleased. A minimum number of records (around 20) got messed up. Steve basically blamed me for it. The explanation he gave didn't ring true with me. Basically, Steve says that I did something which altered the primary key on one of the tables in the database. After I got off the phone with him, I checked the back-up versions of the same database. NONE of the tables have ever had a primary key that I can see. I get the distinct impression that someone is pissing on my boot and telling me that it's raining.
I'm going to pay Elliott and Steve to put this table back to rights, but I've become very leery of handing over $5-10,000 or more on re-development of our second database when my faith in their abilities has significantly diminished.
I'm not dedicated to Access. If moving out of it will solve more problems than it causes, I'm all for it. I'm leaning in that direction. I'm willing to invest time and effort in learning how to work with a new developer (if that's what I'm asking for). The organization isn't big (rich) enough to support an on-call database administrator, so most of the day to day stuff falls to me. It would be helpful to work with someone who understands this and doesn't dismiss me with "it's much to complicated for you to understand."
Any other advice or notes?
posted by Vavuzi at 2:27 PM on August 2, 2010
Vavuzi, I sent an email to the email address you've got in your profile. Either send me a MeFi Mail or reply back to me and we can chat further. I'm not offering services, but I can help you narrow down what you really need and figure out the best approach moving forward.
posted by SpecialK at 9:00 AM on August 10, 2010
posted by SpecialK at 9:00 AM on August 10, 2010
This thread is closed to new comments.
posted by These Premises Are Alarmed at 4:03 PM on July 30, 2010 [1 favorite]