Might be starting a company... which SQL to use?

M

mrjminer

Limp Gawd
Joined
Nov 22, 2005
Messages
413
Update: Going with MySQL / PHP to start with, thanks for the help!

My friend is graduating with a degree in interactive media (I believe that's what it's called) and we are thinking of starting up a small web design company. My friend has an novice-intermediate grasp of various languages, and be more proficient with html, flash, css, graphic design, and java.

I have a B.A. in English (I was a high-school English teacher), but I've worked with computers fairly extensively. I understand the concepts and structures of the various language very well, I just haven't used them regularly / coded them with great depth or complexity, so I'm probably more of an "advanced novice." My role would primarily be coding the back-end.

Now, I started studying MySQL in my spare time about a month ago, but I recently tried to sign up for the Dev I exam to get certified -- but it costs $300. Those of you familiar with MySQL certification probably know this already, but there are four tests. This is a total of $1200 that I'd really like to avoid spending. So, I perused the equivalent MSSQL offerings and there appear to be two core tests at $125 each for a total of $250.

I know MySQL is free or relatively inexpensive from a licensing standpoint, whereas MSSQL is quite the opposite. However, MSSQL is also loaded with features, which significantly add to its complexity in contrast to MySQL, but I'm not quite sure if there will be a business need for me to develop on a more "robust" database, and therefore I don't know if it would be cost-effective to do so.

I am not interested in Oracle, SQLite, PostgreSQL, etc. I am going with MySQL or MSSQL, at least initially.

Anyways, I am hoping that someone has a few minutes to answer a couple of questions given the following circumstances:

1. We will primarily be servicing small - medium size businesses (realistically, most will be small since we will be a startup).
2. We are both extremely unwealthy, but I can garner the funds to do what is necessary. I'd merely like to spend my money on the best option for what we will be doing ;)
3. We will be exclusively designing websites (perhaps later some web applications).
4. My initial plans have been to go the PHP/MySQL route, so I have no experience with Microsoft based web development.

Questions:
1. Which would be better for the sole purpose of designing / administrating websites with low traffic? Moderate traffic?

2. Would certification be that important for me considering he will have a degree in, basically, web design? (Personally, I care very little for certifications, as they only prove you spent a weekend cramming something like max values for data types into your brain. I'd read the books and learn the actual use of the language with the same capabilities, regardless.)

3. I haven't been able to find a reliable answer on whether or not MySQL is suitable for e-commerce from a security standpoint since most information I've found appears to be more like... propaganda. Is MySQL secure enough for low-moderate volume e-commerce?

4. From a cost standpoint, do you think small-medium sized businesses would be defrayed by the cost increase necessary to use MSSQL?

5. Lastly, if our plans fall through, would I be able to find a job using PHP/MySQL, or do businesses primarily seek those using the ASP/.NET/MSSQL line? (I already know that MSSQL works on PHP, etc., but I'm going out on a limb here and presuming a business is more likely to use MS web development if it uses MSSQL and vice-versa)

Bonus Question: What is your prediction regarding the effect Oracle's acquisition of Sun will have on MySQL?
 
Last edited:
Microsoft SQL Server 2008 Express Edition is completely free. It supports 1 CPU, up to 4GB maximum database size and 1GB of RAM.

http://www.microsoft.com/express/sql/default.aspx

If you need more than that then you'll have to consider that once you come upon a database space consideration. For a small business with a relatively low number of webpage hits per day (less than a few thousand) I don't think you'll have issues using the Express Edition.

2.png
 
I'd really urge you to reconsider Postgres. It's by far the best open source RDBMS IMO, and certainly competitive with MSSQL.

I wouldn't consider MySQL for this, but I have a probably unreasonable bias against it, but there are certainly many valid reasons to avoid it, especially with the recent licensing issues and concern about Oracle's involvement; nevermind its technical inferiority to pretty much every other solution out there.

I'd also be concerned about using MSSQL in a PHP environment, especially if you're planning on a single server for both DB and web. IIS/PHP is fraught with issues, and Apache/PHP on Windows is not as reliable and doesn't perform as well as Apache/PHP/nix. If you're planning separate servers I wouldn't be as concerned about it, but I still feel that since you'd represent such a small segment of PHP users, you're more likely to have issues and less likely to get support in resolving them.

As far as getting a job later, most of your SQL skills will be transferrable; you'll have to learn some new syntax but the core syntax and design skills will transfer. It would certainly be easier if you knew one of the 'standard' platforms and could demonstrate that, but skill-wise, it doesn't really matter with DBMS you use and you'd be able to learn another easily. Doing the PHP->.NET transition would be a lot more painful, but going from PHP/MSSQL to PHP/MySQL should be pretty painless, especially if you use a DB abstraction layer as your 'standard procedure'.
 
Answers to the questions:
1 - Either is fine. Though any refactoring from taking an app from 100 hits a day to 10 thousand (or 10 million) requires work. Also see comment "A" below.
2 - Most small/mid sized businesses may not care to see credentials as opposed to a portfolio of completed work. So from a project/revenue perspective, I don't see the (lack of) certifications as a deal-breaker.
3 - The only concerns I have for any common database app (ex: Oracle, SQL Server, MySQL, etc.) come more down to: network access, user account capabilities (utilized by the app's connection string), audit logging, and backup schedule. Aside from these points, I think your "security" concerns would be better shifted to the application architecture and design.
4 - Given the scope of apps you've stated your target customers would want, I don't immediately see a need for full-fledged SQL Server. Express Edition may do just fine. Or MySQL. Or an XML file. Your call.
5 - There are wrappers and connection strings available for having PHP or ASP.Net to connect with a wide variety of data sources. Some connection methods/objects/libraries may be preferred or recommended over another. But within this realm, you can always fall back to ODBC connections.
Bonus - I don't see MySQL's user base being cannibalized, if that's what you're thinking.


Side thoughts on this post:
A - Your technical path may not be your decision to make. If the client has a host or host their own, then your pool of choices may already be more limited than you think. This is on a project-by-project basis.
B - Don't equate "features" with "complexity". Even simple programs can be unwieldy to operate/use/adapt.
C - Part of "B" also ties in with a general viewpoint of this post that favors PHP/MySQL... but it seems more from uninformed and ill-perceived assumptions on dollar cost, instead from a technical or feature perspective that is relevant to your goals. I'm not going to tell you a path to go down, as I see the merit of both. But I do want to emphasize this observation, and that you make technical decisions for project-appropriate reasons. Such reasons include, but not limited to, the following: stated requirements, short/long-term maintenance capabilities, and developing along congruent paths with the technical direction of the client's business market.
 
All of you bring up valid points and options. Awesome responses.

Tytalus/PTNL:
Thanks for bringing up SQL Server Express. You guys are right that this would be a suitable option for what I'd end up doing; I'm not anticipating any clients we'd have (initially) coming close to the imposed resource restrictions.

--
Keenan:
I'll do some more research into Postgres. You are right that it has more functionality than MySQL and is probably more competitive with MSSQL from a functionality standpoint. The reason I eliminated it from my options is because it does not appear to be used as much, so I couldn't find a lot of reliable information from a performance perspective. Most of the information I could find regarding it was users of other DBMS comparing 5-10 year old comparisons of Postgres to recent versions of their preferred DBMS.

Also, thanks for bringing up possible support issues with PHP + MSSQL. It does look like something to avoid for someone with my level of experience due to the smaller supportive userbase. I'm taking this combination off the table for now simply because I'm not going to have the expertise to deal with potential problems in a timely manner.

--
PTNL:
1. I didn't really consider that clients would have systems set in place. I've been thinking of this in terms of a "building everything from the ground up" perspective. I *think* that most of the market we would be dealing with would not have systems set in place, but it is definitely possible that we would have to work with existing solutions.
2. This is what I was thinking, as well, especially since my friend will have a degree to back up any concerns on the odd chance we're asked for something other than a portfolio / working examples.
3. I'm going to look into connection strings to see their connection limitations/implementations. I doubt that we will encounter problems on the small business end using something like ODBC/C, but I this is a valid concern when approaching simultaneous connections / activity for a medium-sized business. I presumed that any of the DBMS choices would be apt for logging, backup, and security for e-commerce and that it would fall on the design, so thanks for verifying this.
4. Agreed.
5. I'm probably just going to use whatever default comes with the SQL DMBS I go with while I learn (the only one I even know anything about are ODBC, and I don't know much about those!) but I'm going to look into them a bit since they may effect the path I'll take.
Bonus: Thanks, that's what I was thinking.

Additionally, you're right that I have been factoring cost into a large portion of my decision-making process. The reason I am concerned about this, though, is that small businesses might not have the funds necessary for a more expensive solution. Money is not a significant issue for me (but, of course, like everyone else I want to get the best bang for my buck!), I'm just concerned that choosing a more costly solution that has to be passed on to our customers would exclude some small businesses, but from everyone's posts it's pretty clear that there's a free solution that could cater to the "very small business."

--

I'm going to do some more research on some of these issues, thanks again guys.
 
mrjminer said:
I am not interested in Oracle, SQLite, PostgreSQL, etc. I am going with MySQL or MSSQL, at least initially.
Click to expand...
By what criteria did you rule out Oracle, SQLLite, Postgres, and etcetera? Why do those criteria not apply to MySQL or Microsoft SQL Server?

mrjminer said:
1. Which would be better for the sole purpose of designing / administrating websites with low traffic? Moderate traffic?
Click to expand...
The in-box SQL Server tools are far better than the MySQL tools, and any of the third-party tools for MySQL I've used, as well. (You won't believe me, but I really am saying that for reasons beyond having worked on them.)

mrjminer said:
2. Would certification be that important for me considering he will have a degree in, basically, web design? (Personally, I care very little for certifications, as they only prove you spent a weekend cramming something like max values for data types into your brain. I'd read the books and learn the actual use of the language with the same capabilities, regardless.)
Click to expand...
If you're going into business for yourself, the decision is yours, isn't it?

mrjminer said:
3. I haven't been able to find a reliable answer on whether or not MySQL is suitable for e-commerce from a security standpoint since most information I've found appears to be more like... propaganda. Is MySQL secure enough for low-moderate volume e-commerce?
Click to expand...
MySQL and SQL Server are both secure. Most of the security problems people have are because of operational, configuration, or development mistakes they make, themselves. The biggest danger to your security is you and your employees, not the product you choose.

mrjminer said:
4. From a cost standpoint, do you think small-medium sized businesses would be defrayed by the cost increase necessary to use MSSQL?
Click to expand...
SQL Server Standard Edition costs less than six grand. You can figure you'll upgrade every two or three years. A comparable MySQL license, with support, costs $3000 per year. MySQL is about the same price, or more expensive.

mrjminer said:
5. Lastly, if our plans fall through, would I be able to find a job using PHP/MySQL, or do businesses primarily seek those using the ASP/.NET/MSSQL line? (I already know that MSSQL works on PHP, etc., but I'm going out on a limb here and presuming a business is more likely to use MS web development if it uses MSSQL and vice-versa)
Click to expand...
You can find a job with either skill set.

mrjminer said:
Bonus Question: What is your prediction regarding the effect Oracle's acquisition of Sun will have on MySQL?
Click to expand...
Nothing. The problems for MySQL started when Sun bought the MySQL team and IP. I think it'll just get worse if Oracle finishes buying Sun.

Another issue to note is the rest of your platform. It's easier to connect Microsoft technologies to SQL Server than it is to MySQL. It's easier to connect open-source languages (Python, Perl, PHP, Ruby, ...) to MySQL than it is to SQL Server. Integration and cross-connection is possible, but doesn't result in the simplicity and fidelity that the homogeneous connection does.

In the end, I think you're worried about the wrong thing. Your lack of experience and ability to make decisions is going to carry far more weight than your choice of database server software.
 
Last edited:
mikeblas:
My criteria applied to MySQL and Microsoft SQL Server, they just didn't fail the test :cool: . I'm not going to be working on huge websites, so Oracle would be overkill. SQLLite has too few of resources available for my taste. I added PostgreSQL back into my candidates earlier.

1. I like the simplicity / layout / look / feel of the MySQL one, but I have no doubts that you're right about Microsoft's being better since they tend to put out pretty good front ends to their coding programs (I love the C# one, I like their SQL Server one slightly less than MySQLs in the hour I was dinking around with it, but I'll try it out a little more).
2. Yup, I actually got a hold of my friend and he thinks I might as well screw certification, as well, so that's what I'm going to do. It's going to save me so much time not memorizing materials I can just look up on a chart. I'm very excited because now I can just jump right into it.
3. You're right on this one, I did more searching on the issue last night and found that the ball is going to be in my court for this one.
4. As you've all pointed out, the MS offering would, realistically, be much more affordable than I originally anticipated. Also, thanks for the numbers on official company support. I don't think I would need 'official' support, but I'll stick this into my tie-breaker column as advantage-Microsoft (not necessarily because their support would be better, I just have no experience with MySQL's support team--and I'm unsure of how the quality of this would be effected by Sun being bought).
5. Good to hear that everyone has the same opinion on this issue. It takes a load off my mind to know that I'm not going to make an overly incorrect decision based on this question.

I had a feeling that connecting MS offerings would be easier to connect to MS offerings and vice-versa, so thanks for verifying that.

Overall, I think everyone here is giving me the impression that it's going to make more of a difference on how well I implement it than which one I pick. I've worked with enough knuckleheads like me to know you guys are right, so thanks for making sure I am aware of this :D
 
While using the right tool for the right job is the ideal, people generally stick to what they're used to.

I work with SQL Server, MySQL and Progress on a daily basis. My previous job was almost solely Oracle. I have PHP scripts that connect to both SQL Server and MySQL to build pages. I also have DTS packages that automate SQL Server -> MySQL data sharing. I have found that, for most of my work, it doesn't really matter which one I go with. For some specific things, I have favorites. For Data Mining/Warehousing I like SQL Server. For GIS, Postgres (PostGIS). For almost any web project: MySQL. The majority of my work currently involves web projects and the LAMP framework. I do have some that are mixed though... WAMP, WIMP, "LASP". I find that when I start something new, I just assume LAMP unless something changes that.

So, while right tool for the right job is good, just go with what you're most familiar with. The job will still get done.
 
If you're noobs & doing small business sites, it's highly unlikely you'll be called on to do more than a few contact forms & simple CMS-like stuff. PHP/MySQL is fine for this & you can find extremely low-cost hosting plans.

It really doesn't make a difference what you use for low/medium traffic sites. Since you know PHP/MySQL, go with it. It's fine for simple web dev.
 
I would urge you to consider web frameworks like ruby on rails or django. They really abstract a lot of the database muck and allow you to focus on the site. Ultimately, when you start abstracting things, the choice of database doesn't make a huge difference.
 
mrjminer said:
mikeblas:
My criteria applied to MySQL and Microsoft SQL Server, they just didn't fail the test :cool: . I'm not going to be working on huge websites, so Oracle would be overkill. SQLLite has too few of resources available for my taste. I added PostgreSQL back into my candidates earlier.
Click to expand...
What I'm asking is: what is that criteria? Oracle sells a few different versions at different price points, and calling it "overkill" but implying SQL Server isn't has me a bit baffled.
 
Maximus:
Thanks for some working examples to give me a better idea of how each would be used in different environments / situations.

ameoba:
You're right that this is likely what we will be doing in most cases. I'm just trying to make sure that it will be a solid option for this purpose and will provide us with enough scalability for future endeavors :)

Mcot:
I just talked to my friend last night and he told me to check it out, too. I'm still going to be focusing on a DBMS for now, but I'm going to check out Ruby on Rails when I get time. I haven't heard of Django, but I'll look at that one, as well.

eloj:
Thanks for the vote.

mikeblas:
Primarily, use as a web DB for small-medium business environment. I'm under the impression Oracle, while suitable for small-medium business use, is more expensive and will not offer a real benefit for our particular situation. If we were planning on servicing sites that had more traffic or higher amounts of simultaneously connected users, Oracle would be in the running. Additionally, I think SQL Server / open-source offerings would align more easily with other web languages (although that will probably change a bit since Oracle will own Sun soon). I don't have a problem with Oracle if that's what you're thinking, it's just a problem with what we'll be doing with it.

---

Verdict:

After everyone's thoughts and researching based on everyone's input, I've decided to go with MySQL / PHP initially. I'll probably end up learning SQL Server and some Postgres in the future, too. Overall, I think it will be easier for me to learn MySQL to do everything we're going to have to do at the start of our business, and will prove to be a good stepping stone into the other DBMSs for when I get a little more experience to take advantage of what they offer over MySQL.

Thanks for all of the suggestions and information guys! If I had money, I'd paypal you each $5, but I dont, so thanks for the charitable contribution :D
 
mrjminer said:
ameoba:
You're right that this is likely what we will be doing in most cases. I'm just trying to make sure that it will be a solid option for this purpose and will provide us with enough scalability for future endeavors :)
Click to expand...

Don't overthink scalability. You're not Facebook, Google, Amazon or Twitter. Any project you start will likely not be like them either. Get it out the door able to handle the load you honestly expect the site to see - not the sort of load you wish it'll get.
 
I think my only objection to your decision would be that MySQL will teach you bad habits you're going to have to un-learn if you ever want to transition to a real DBMS. As far as a practical solution for what it sounds like you're going to be doing though, it's a good choice.
 
ameoba said:
Don't overthink scalability. You're not Facebook, Google, Amazon or Twitter. Any project you start will likely not be like them either. Get it out the door able to handle the load you honestly expect the site to see - not the sort of load you wish it'll get.
Click to expand...

Oh no, don't get me wrong, when I say scaleability, I mean going from maybe 10 people using a site at a time to 40 :cool:


keenan:
Thanks for keeping me aware of this. One of the reasons I'm going with MySQL is for how quickly I'll be able to do it compared to how long I think it's going to take me to learn a different one. I don't mind un-learning a bit if I have to, I'd just rather get started on it sooner and get some working copies going to experiment with them.
 
Scalability, like security, has a lot more to do with your design than the underling database management system.
 
If your design involves a terrible way to populate, lable, and order the physical folder within the file cabinet, it will certainly be slower than other designs also relying on a file cabinet--regardless of the brand of the cabinet.
 
Which choices did you end up making, mrjminer?
 
Oh, thanks. I guess with the edit, the post doesn't show up in my subscription lists.
 
You must log in or register to reply here.
Back
Top