Is it difficult to learn databases?

[knick]

A little while back I had an idea for a useful piece of software. Since then I have been using a lot of my spare time to learn software development. So far I have learnt;
- UML
- OOP concepts (inheritance, polymorphism, etc)
- The basic OOP design patterns (strategy, decorator, etc)
- C# programming language
- Some of the basics of the .NET libraries (collections, etc)
- Unit testing in visual studio
- Currently reading a book on Domain Driven Design

So, I'm well and truly past the "hello world" stage and I think I might even be ready to start coding my application. There is just one thing which I think might hold me back... persistence. My application will have some pretty complex domain logic, and I will need some way of preserving the state of domain objects between sessions. This poses a problem, since I currently have no experience with databases - and I would prefer to keep it that way if possible! I don't really want to have to learn databases upfront. If possible I would prefer to pay someone else to add persistence at a later stage when I have the rest of the software up and running.

So, my questions are;
1) Do I need to learn databases upfront? Or can I develop my domain logic now, and then add persistence later (almost as an after-thought)? Would this be easy to do, or will I completely have to tear up my code to make it work?
2) How much time will it take to learn databases? If it took me a month of my spare time to learn UML, and 2 months to learn C# & .NET basics... how long should I expect to spend on learning databases? Looking in from the outside, databases appear to be quite a complex subject.

Any advice from someone who has experience in building persistence into domain logic would be greatly appreciated!

[oracleguy]

Well do you need a database? You don't necessarily need one to persist program settings; depends what your application is doing and what data you need to store.

There are two distinct things to learn about databases, SQL and actually designing a good schema. If you make a bad schema it will make using the database much harder and it will be harder to expand it with additional columns or tables later.

[knick]

Do I need a database? Good question. What is the alternative? Writing data to an .ini file, .XML file or some other proprietry format?

I've already learnt a little bit of LINQ and I'm hoping that might shield me from having to learn SQL. So I guess its more the schema design that concerns me.

[oracleguy]

Those are all options yes, I would say an XML file is your best bet between the three. If you are using .NET, it is pretty easy to work with XML files. And if you are lazy you can always use the XSD tool that comes in the SDK to create classes from a schema that are serialize-able.

But it depends how much data you will be storing and how you will need to access it. If you are going to want to do lots different searches on the data, using a database will be easier.

[knick]

oracleguy: I don't know what XSD is but I will definitely look into it - thanks for the tip.

indiadatacentre: thanks for your estimate. At least it gives me some idea of what I am getting myself in for.

I still haven't received any feedback about whether it is feasible to forget about persistence for now and add it later. What is the normal process? Is this likely to get me into trouble? Would an experienced developer design persistence in right from the beginning?

[Fumigator]

In general, if a feature is not required, i.e. your system works without it, then you can leave it out of version one. If your system doesn't work without a feature, then you need to design and build your system with that feature included from the start.

Also keep in mind your first project is not going to be great. It may even suck. But that's the way it goes... your second project is going to be better than your first, and so on. You will learn from each experience and figure out how to build things better.

[knick]

Fumigator,
Yes, I have considered the very real possibility that my first attempt is going to suck quite badly. My background is in designing electronic hardware. When I look back at the first PCBs I designed 7 years ago, I have to conceed that they are 'less than ideal'. If I were to do those projects over again I would certainly do things differently this time around.
But in some respects I think software is more forgiving. The first piece of hardware I designed is still in service today, in its original 'sub-optimal' form. Whereas some of the early software projects (matlab) that I worked on exist today in a nicer refactored form. I guess what I'm saying (or hoping) is that improving design and fixing mistakes is much cheaper in software engineering than many other disciplines. When I come to the realization that my first attempt sucks, I will keep refactoring until i get it to an acceptable level of suckiness