phoenix said:
Due to the requirements of his project, perhaps? Afterall, would you really consider SQLite when designing a student information system?
More than likely not, but we have no idea what the scope of this "system" is to be. The OPs first post indicated nothing that could steer a choice other than (C | Manage some student data | easy to learn | no experience). A follow up post later added += (client/server may be better).
Perhaps the system in question is a write once read many sort of solution, with one writer and many readers. Perhaps the solution is more of a reporting solution, something that sources its data from another solution where it is housed, nurtured, protected. Maybe it's a one-off prof's tool. Maybe it would benefit by being both on line but also portable, storable on a USB drive or a CD? I can think of many situations where sqlite or other non-RDBMS data management tools would be entirely appropriate.
However if the solution requires a high degree of concurrent write and read access; is the principle tool for interacting with and producing new data (i.e. can't be replaced from some other "mother" system); if the solution potentially needs to interact with other software particularly if that software would not be under the author's control, or a host of other situations I can think of - no, I'd opt for a more traditional SQL based solution over sqlite.
I also do not see the choice of sqlite as excluding the use of another RDBMS for a real production system. I said:
I said said:
While I do favour Postgresql if your primary goal is to get some SQL experience the advice above to look at sqlite should not be ignored.
By this I mean that sqlite source being installed gives the OP a learning ground. If the system is of any significance, the OP's real learning curve is SQL. If it's a minor solution, then learning library calls and SQL are about the same level of complexity. My thought is that sqlite gives the OP a platform to learn some SQL without having to also take on the task of earning how to install and manage a client server DB. But if that is also part of the OP's job responsibility, then yes, indeed he should just press on with a suitable tool for the production system.
Along the same lines, if "learning SQL" before "designing application and database" is a key requirement, in addition to using whatever command line console the DB of choice provides, I would suggest learning sql via the use of a so-called scripting language (only if the OP already is familiar with something like perl or ruby or python or php) to flesh out how your app code is going to interact with a DB. The OP is likely to find doing some exploration in that environment allows for a much more rapid rate of learning, and prototyping solutions in a page or two of python, for example, can often be done in a quarter of the time of many pages of C, especially when there is much new ground to cover.
You also responded to:
I said: More seriously, why limit your quest for knowledge to SQL only?
I injected the thought of being open to "something other than SQL" because sometimes something other than SQL is completely appropriate. Chances are if someone has next to no SQL experience, they probably haven't been exposed to other forms of data management tools. There is a big world out there beyond MySQL, Progress, Oracle, MSSQL et al, and thanks to today's hardware and networks and application architecture styles many solutions are appropriately backed by data stores other than SQL databases.
For all we know this solution has as a principle requirement the management of highly unstructured data that might be better housed in another type of data repository altogether. Or perhaps the data is extremely hierarchical in nature, a situation which an inexperienced SQL developer will find very challenging indeed.
Unfortunately, as is very often the case in threads like these, the OP's "requirements" are sketchy and lead to no definitive direction. Too often the early comments are more about technology rather than nailing down what is the basic problem that needs solving.
Granted, it's a student system of some sort and we (particularly you with your experience) can probably guess as to some of the likely technical requirements. I just prefer not to limit my guesses until the solution needs are more fully detailed, and I also prefer to consider tools other than the hammer because
when all you have is a hammer, everything looks like a nail.
PS to the OP: in case it's been forgotten through my verbosity +1 for Postgres was my initial response.