You are most likely best served by relying on the capabilities of the query engine of your database backend, e.g. map user queries to SQL queries. The third step is to design an appropriate system and data model. You can find documentation on the dbSNP datamodel here ftp://ftp.ncbi.nih.gov/snp/database/erd_dbSNP.pdf which is most likely too complex for a single lab design. The second step however (after a requirement analysis, saying that you are doing the third step before the first) is to question your aim of re-inventing the wheel. Do you really have to waste time on developing such a database system from scratch or at all while dbSNP, SNPedia, BioMart, etc. exist which are sufficient for most use-cases?

If you really need an in-house SNP database, please consider the following:

• Re-do your requirement analysis, most likely you are not modeling your domain correctly if you only allow for SNPs, but not for small insertions and deletions. Having mis-modeled such a core part of your domain implicates further deficiencies.

• Do not choose your tools, languages and approaches before having modeled your domain and use-cases correctly (agility is not an excuse for bad planning)

• Consider use of existing software tools
• Don't approach the problem with this "I will do X, I want to use programming language Y" mind-set, if you can't give a proper rationale for your plan.

Unless there is a tool on the web that allows the user to "harmonize" rsID numbers with all the other stupid nomenclature out there, then I think that would be a great idea, Of course, I work in the arcane backwater of 'pharmacogenomics', where star alleles dominate.