My college (UK) computer science course work requires me to create a program as apart of a project. I have decied to do a basic stock room program (for a clothing store). Clearly this would require the use of a database. I have expereince in pascal/delphi and some python (havn't touched it in 2 years though). But was wondering what the best lanuague would be for this kind of database work. I have the time to learn a new lanuague in preperation. I was curisous to see if anyone with any expreince would recocomend any particular lanuagues and software packages to help me in completing my project.
I personally use C# and Entity Framework for quite a lot of application <=> database work as it is IMO really easy to work with. Also there is a good amount of documentation on how to use it and the best practices.
just adding a question: do you want to abstract the database (connection) or directly execute sql queries (or prepared statements even to add a layer of security)
Not really concerned about security since it is a project (and won't be implemented), I think direclty executeable sql queries would be the way to go (as it would be simplier ( correct me if I'm wrong)).
then you can use whatever language you are most familiar with, because most support direct db interaction.
Or simply see sql as the "new language" and use the command line to interact with the db.
hard to say, there might be languages out there that are abstracting the db really nice (C# afaik) so only operating on variables and only very short to no direct sql queries.
but if the goal is to get to know the database (psql, mysql, db2 or oracle ?) then direct sql is the way to go.
The thing is pascal/delphi (what I'm primarly used to ) is a very unused language ( mainily used for teaching) and has little package support, I seem to infere that a C, C#. Route would be the way to go ?
wouldn't go that far, because in the old days those weren't only taught, but also used in economy. They do support packages that allow db connections, odbc being one of them.
Write the app in the language of your choice and do the db last. While there certainly are performance and clarity issues to think about when making a db, what your app does should not be constrained by anything in the db, the db should simply provide what the app needs. The objects you create in your code will inform what you need in the db. Might look into MongoDb too.
the db definition should be done prior any programming or choosing of language.
also, why not use the db to its fullest. Instead of using multiple for/while loops, if statements and similar: use a nice crafted sql-statement / function / view. Not too much logic needed in the main program code.
Depending on the project MongoDB (storing data very ineffective and when doing certain operations can be very slow) might not really be the right choice!
@Joshua_Warren
also some educational personal might tell you to use a db nothing newery fancy that aint that good after all. stick to SQL, the non rational sql aint as good as it wants to be in reality. @see http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality
Why not use the code to it's fullest? I'm not sure what you mean about all the loops. I've written a lot of SQL, one of my colleagues says I like it too much, and you can practically write a console application using nothing but SQL, but a lot of people get bogged down in db architecture to the detriment of app architecture and eventually to the detriment of over-complicating the db. My goal now is to make coding against any db as easy as possible, and keep logic out of it. There are different philosophies, and I encourage learning about more than one, but for greenfield I would definitely do code first.
I was just suggesting MongoDb type db's as a fun thing to look at if it's his own project, haven't used it much. I'm interested to see how SQL works with JSON in the newest iteration.
for small learning its great, but not for a small project during class.
as for complicated design, you are right. There should by no means be redundant data, too many similar information or anything of that kind. The smallest set of primary keys/foreign keys should be used. BCNF, 3NF or smaller. hope they are about to learn that in the class too.
hehe, this is why I've seen some really badly designed database solutions. It's the right approach if you need an application that just so happens to need a data store - and this is where the NoSQL stuff like Mongo can also work really well.
For a stock room app like the OP describes a traditional approach to a database-application would usually be best. The application part is really just a user-interface and most of the business rules and logic correctly implemented in the database to properly guarentee data-consistancy and quality.
Langague wise there is choice. Going Microsoft with Visual Studio, C# and T-SQL would be an easy path to take, all the required tools are free. There are also tutorials and demo databases such as AdventureWorks available for you to hack around with. https://www.visualstudio.com/products/free-developer-offers-vs
If the OP prefers a completely open-source path the traditional LAMP (Linux/Apache,MySQL,PHP or Python) stack solution would work well for the requirement and is generally easy to setup.
If you're making an server client program, id say use either java or C# as the back end of the system. Using servlets/res services really makes your life easier. Front end can be pretty any language, but the higher tier languages(java/C#/etc) are abit easier to handle serialization of objects and so on though. but since you're making a clothing store why not make a java/c# back end, here the worst case is you need to include a driver for your database protocol(incase you use mysql, or oracle), and do request from a web based front end, just as an icing. For a front end webpage if you can use something like M$ visual studio, it just becomes stupid easy, and basically becomes a drag and drop job with a few double click edits of some object event listeners, and pretty much regardles wether you use java or C# as a back end the syntax is approx 75% the same.
hehe, Designing something badly has nothing to do with philosophy of development, you have to pay attention to what you're doing and learn your tools. All apps do just so happen to need a data store. You won't need the data unless you have a process that operates with it. If this app is simple, the db should be equally simple. If this app is complicated, the db should still be simpler. I would under no circumstance currently advocate for a "traditional" database first design. Do you write tests around your SQL and have it in source control? Code first is not a "newfangled" thing either. Regardless, I hope no one here is trying to convince OP not to learn multiple ways of doing things. Every shop you work in could be very different, agility is essential.
There is no need to make even a traditional application/database design complicated. Most contemporary database engines have great features these days that reward those who take the time to learn them. I've seen ridiculous solutions where a dev team have spent weeks/months building complex solutions to generate unique ID's and data-replication tools only for the functionality to already be in the RDBMS. Likewise, I've worked with other teams who decided no logic in the database on the grounds of simplicity only to then make far more complicated application code than if they had just written some stored procedures and functions into the DB.
Mind you the same teams also used Mongo because their app had a tiny bit of JSON in it and no modern RDBMS can handle that... Get data from RDMBS, munge in application, write to MongoDB, get from MongoDB, munge in application again and write back to RDBMS... ...please make it stop...
...I have worked with some terrible devs.
I hope I have not put the OP off working with application and database development :-D