Ask HN: Excel vs SQL

#1

Post by keecham » Fri, Jan 13, 2012, 5:15 PM UTC

Hi all,

We're in the process of building out our database for our website, and have currently run into an interesting dilemma: whether to use SQL or Excel to contain our data. Either database needs to be uploaded to our site, and our site revolves around a search engine that will need to look up and return results from the database. We're currently using mostly PHP on the site with AJAX for the search engine functionality.

We are contracting the work out, and one set of developers insist that SQL is more appropriate for our project. I typically have only used SQL for dealing with very large amounts of data, which we do not have in our database, which is currently only about 300 rows and 15 columns long.

What are your thoughts? Thanks for any advice.

Re: Ask HN: Excel vs SQL

#2

Post by swasheck » Fri, Jan 13, 2012, 5:23 PM UTC

Without any sense of what your project will be doing it's a bit difficult to forecast data growth, reporting needs, etc.

Having said that, I don't really see Excel as a legitimate choice for being a data back-end. It is a front-end for data analysis (IMHO). It's like using a pocket knife as a screwdriver: it can do the job in a pinch, but it's not the best tool for repeating the same task many times.

With that out of the way, I'd say that SQL is the better of the options because that's the job it was meant to do - irrespective of data set size. Sqlite is a fabulous tool that should meet all of your requirements.

http://www.sqlite.org/

Go forth and prosper.

edit: I forgot to mention that it also supports Full-Text Search which may be handy for your search engine application (if that's being developed in-house).

(another) edit: With 15 columns, I wonder if normalization might be an intermediate step.

Re: Ask HN: Excel vs SQL

#3

Post by keecham » Fri, Jan 13, 2012, 5:39 PM UTC

swasheck wrote: post #2

Without any sense of what your project will be doing it's a bit difficult to forecast data growth, reporting needs, etc. Having said that, I don't really see Excel as a legitimate choice for being a data back-end. It is a front-end for data analysis (IMHO). It's like using a pocket knife as a screwdriver: it can do the job in a pinch, but it's not the best tool for repeating the same task many times. With that out of…

Thank you for your input.

In terms of database normalization, doesn't that usually require redundancy (repeated columns / records)? We have that once over two columns, but otherwise there are no repeats - each entry is unique.

Pardon my ignorance, not much experience with database software as is clearly evident haha.

Re: Ask HN: Excel vs SQL

#4

Post by swasheck » Fri, Jan 13, 2012, 5:45 PM UTC

keecham wrote: post #3

swasheck wrote: post #2

Without any sense of what your project will be doing it's a bit difficult to forecast data growth, reporting needs, etc. Having said that, I don't really see Excel as a legitimate choice for being a data back-end. It is a front-end for data analysis (IMHO). It's like using a pocket knife as a screwdriver: it can do the job in a pinch, but it's not the best tool for repeating the same task many times. With that out of…

Thank you for your input. In terms of database normalization, doesn't that usually require redundancy (repeated columns / records)? We have that once over two columns, but otherwise there are no repeats - each entry is unique. Pardon my ignorance, not much experience with database software as is clearly evident haha.

Well, existing redundancy is an indicator that a structure can be normalized right now. I guess the way I conceptualize normalization is that it reduces the possibility of storing redundant data now, or in the future.

Not saying that it is 100% effective and fool-proof ... just the ideal.

BTW, here is the php manual entry for sqlite http://php.net/manual/en/book.sqlite.php