OODB or RDB for checkbook/budget program?
-
Hi, I wrote myself an Access db several years ago to do some things for my checkbook and budgeting and I've really enjoyed it ever since. Lately I've been thinking about writing it as a stand alone program so I could let my family and friends use too (I don't want it to be Access dependent because I don't want to have to troubleshoot and support it on different versions of Access or MDAC). Anyway, I once took a class on OOP Logic and a C++ class, and as I was thinking of how to design it, I was thinking in terms of objects. For instance, a transaction would be an object with attributes like a date, amount, etc. But then I realized that designing it this way seems to be fundamentally different from the way I did it originally with Access. So it looks like the first big decision I have to make is to decide whether to use object oriented db design or relational db design. Is this true, and if yes, which way would be better to go for a checkbook/budgeting app? Thanks for your help.
-
Hi, I wrote myself an Access db several years ago to do some things for my checkbook and budgeting and I've really enjoyed it ever since. Lately I've been thinking about writing it as a stand alone program so I could let my family and friends use too (I don't want it to be Access dependent because I don't want to have to troubleshoot and support it on different versions of Access or MDAC). Anyway, I once took a class on OOP Logic and a C++ class, and as I was thinking of how to design it, I was thinking in terms of objects. For instance, a transaction would be an object with attributes like a date, amount, etc. But then I realized that designing it this way seems to be fundamentally different from the way I did it originally with Access. So it looks like the first big decision I have to make is to decide whether to use object oriented db design or relational db design. Is this true, and if yes, which way would be better to go for a checkbook/budgeting app? Thanks for your help.
Here's some thoughts of the top of my head.
copec wrote:
whether to use object oriented db design or relational db design
It's not an either/or decision. If you think of the app as having two parts (i.e a user front end and a data storage back end), the front end could be OOP and the back end a relational db. The two ends have to communicate and you can do that in a number of ways, two possible approaches are: 1. Use the data binding common in MS Windows forms and IDEs such as Visual Studio. This is essentially what Access does when you build forms using the wizards. 2. Put a data access layer (DAL) between the front and back ends. Possibly Model-View-Controller pattern. Enterprise solutions ought to go down this path, but it might be overkill for a single user app. If you don't want to use Access you have to decide how to store the data. Options include: flat files (CSV?), XML, some other database. You need to determine what the other users have on their machines before deciding. "Thoughts of a dry brain in a dry season" - Gerontion, T S Eliot. :)
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
Here's some thoughts of the top of my head.
copec wrote:
whether to use object oriented db design or relational db design
It's not an either/or decision. If you think of the app as having two parts (i.e a user front end and a data storage back end), the front end could be OOP and the back end a relational db. The two ends have to communicate and you can do that in a number of ways, two possible approaches are: 1. Use the data binding common in MS Windows forms and IDEs such as Visual Studio. This is essentially what Access does when you build forms using the wizards. 2. Put a data access layer (DAL) between the front and back ends. Possibly Model-View-Controller pattern. Enterprise solutions ought to go down this path, but it might be overkill for a single user app. If you don't want to use Access you have to decide how to store the data. Options include: flat files (CSV?), XML, some other database. You need to determine what the other users have on their machines before deciding. "Thoughts of a dry brain in a dry season" - Gerontion, T S Eliot. :)
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
Thanks David. Wow, you used a lot of words a phrases there I've never heard before. It's good news (I think) that I can use my OO knowledge with standard RDB tables to store the data because I already have a working model in Access and I understand a little about OOP. How do I decide what language, db, gui, toolbox, etc to use keeping in mind: 1) I have a little c++ training, 2) need the most stability I can reasonably get, 3) free tools that I can sell if I decide to one day? btw, Windows only compatibility is fine, especially as I'm assuming cross-compatibility requirements would only make finding a solution more difficult. Thanks again.
modified on Saturday, July 11, 2009 10:34 PM
-
Thanks David. Wow, you used a lot of words a phrases there I've never heard before. It's good news (I think) that I can use my OO knowledge with standard RDB tables to store the data because I already have a working model in Access and I understand a little about OOP. How do I decide what language, db, gui, toolbox, etc to use keeping in mind: 1) I have a little c++ training, 2) need the most stability I can reasonably get, 3) free tools that I can sell if I decide to one day? btw, Windows only compatibility is fine, especially as I'm assuming cross-compatibility requirements would only make finding a solution more difficult. Thanks again.
modified on Saturday, July 11, 2009 10:34 PM
Here are some thoughts. (Rather longer than I anticipated!) :-D If you have a developer edition of Office you can package your .mdb together with a run time version of the Access engine. This would be the simplest thing to do - I believe it would take care of the MDAC issues but have never used it. IIRC the license is that you must have the developer edition Office Pro is not valid. The beauty of Access is that the .mdb file contains everything - user interface (GUI) and data store (i.e. db tables etc). So the whole app can be self-contained (unless you use linked tables). If you move from Access then the GUI and and the data store will be separate components that need to talk to each other. So you have to decide what to use for the data store and what to use for the GUI. Looking at the data store, main driver for this decision has to be 'What do potential users have on their machines?' If they have Access why not stick with it? If they don't then some possible options are. 1. Use flat/text files - the traditional (antedeluvian?) way that requires a lot of coding (having said that, I know of one major UK retailer whose warehouse management system is run using flat files.) This approach would mean that the users would require nothing special. However, you would have to think about securing the files so users cannot edit or delete them. 2. Use XML - this is what many would advocate. Essentially they are structured text files on steriods. But that requires learning about XML. Similar pros and cons to flat file. But there are other benefits and lots of example code on the web. 3. Use an OOP language and the object serialization that is built in. Not always as easy as it seems but would be self-contained. 4. Use a relational db. There are some free ones that you could investigate e.g. SQLite, MS SQL Express. You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access. For the GUI and the ability to communicate with the data store you still have to ask 'What have the users got on their machines?'. You also have to ask 'What am I comfortable with and how quickly can I get uo to speed?' These days you're pretty much obliged to use an OOP language. Possible options are: 1. Java - I once heard it described as 'C++ For Dummies' so knowledge of C++ would be helpful. It's free and cross-platform and there's some nice free IDEs (NetBeans and Eclipse are considered good). Personally I think it st
-
Here are some thoughts. (Rather longer than I anticipated!) :-D If you have a developer edition of Office you can package your .mdb together with a run time version of the Access engine. This would be the simplest thing to do - I believe it would take care of the MDAC issues but have never used it. IIRC the license is that you must have the developer edition Office Pro is not valid. The beauty of Access is that the .mdb file contains everything - user interface (GUI) and data store (i.e. db tables etc). So the whole app can be self-contained (unless you use linked tables). If you move from Access then the GUI and and the data store will be separate components that need to talk to each other. So you have to decide what to use for the data store and what to use for the GUI. Looking at the data store, main driver for this decision has to be 'What do potential users have on their machines?' If they have Access why not stick with it? If they don't then some possible options are. 1. Use flat/text files - the traditional (antedeluvian?) way that requires a lot of coding (having said that, I know of one major UK retailer whose warehouse management system is run using flat files.) This approach would mean that the users would require nothing special. However, you would have to think about securing the files so users cannot edit or delete them. 2. Use XML - this is what many would advocate. Essentially they are structured text files on steriods. But that requires learning about XML. Similar pros and cons to flat file. But there are other benefits and lots of example code on the web. 3. Use an OOP language and the object serialization that is built in. Not always as easy as it seems but would be self-contained. 4. Use a relational db. There are some free ones that you could investigate e.g. SQLite, MS SQL Express. You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access. For the GUI and the ability to communicate with the data store you still have to ask 'What have the users got on their machines?'. You also have to ask 'What am I comfortable with and how quickly can I get uo to speed?' These days you're pretty much obliged to use an OOP language. Possible options are: 1. Java - I once heard it described as 'C++ For Dummies' so knowledge of C++ would be helpful. It's free and cross-platform and there's some nice free IDEs (NetBeans and Eclipse are considered good). Personally I think it st
Thanks so much for this info. A lot of it is new but some of it fits in and clarifies other things that were foggy. It may show that I don't really understand what I'm talking about, but, in no particular order: --I used to support some Access apps that ran on MDAC and Access on various clients and there were always problems coming up. That's why I'm drawn to developing a truly independent program. --I'm definitely leaning toward an RDB data store instead of an OODB, or the other choices, because I already have a working -though improvable- model of the data in RDB (my existing mdb) and it seems like the "best" way to store number data. --From this and other info I've read I guess it's a two way tie between C++ (I had the Intro to C++ class) and Python (seems to be widely liked) for the front-end (is this right terminology?) with Java still kind of in the running (don't love that it is dependent on JVM). --Should I not be concerned about stability or security of using something built on a platform, like JVM or .net? --Could you talk more about this?: "You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access." --I understand what the language and libraries are, but could you explain why I need toolboxes, wrappers (like wxpython)? --Regarding IDEs, I found these at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments[^]. How do I choose between "IDEs with introspection-based code completion and integrated debugger" and "IDEs with integrated gui builder"? And thank you again. I really appreciate your help.
-
Thanks so much for this info. A lot of it is new but some of it fits in and clarifies other things that were foggy. It may show that I don't really understand what I'm talking about, but, in no particular order: --I used to support some Access apps that ran on MDAC and Access on various clients and there were always problems coming up. That's why I'm drawn to developing a truly independent program. --I'm definitely leaning toward an RDB data store instead of an OODB, or the other choices, because I already have a working -though improvable- model of the data in RDB (my existing mdb) and it seems like the "best" way to store number data. --From this and other info I've read I guess it's a two way tie between C++ (I had the Intro to C++ class) and Python (seems to be widely liked) for the front-end (is this right terminology?) with Java still kind of in the running (don't love that it is dependent on JVM). --Should I not be concerned about stability or security of using something built on a platform, like JVM or .net? --Could you talk more about this?: "You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access." --I understand what the language and libraries are, but could you explain why I need toolboxes, wrappers (like wxpython)? --Regarding IDEs, I found these at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments[^]. How do I choose between "IDEs with introspection-based code completion and integrated debugger" and "IDEs with integrated gui builder"? And thank you again. I really appreciate your help.
copec wrote:
developing a truly independent program
Not sure you can develop a completely independent program. If you create an executable (i.e. .exe) it will almost certainly depend on some system .dlls - pretty much unavoidable. It will also depend on having an RDBMS (e.g. SQL Server) if you use a relational db.
copec wrote:
don't love that it is dependent on JVM
You don't need the JVM on user's machines, just the JRE - at least that's my understanding. If you use C++ to create a .Net app, user's would need the .Net framework installed. I don't know Python so don't know its dependencies.
copec wrote:
Should I not be concerned about stability or security of using something built on a platform, like JVM or .net?
These are probably concerns irrespective of platform. How critical they are depends on the nature of the app.
copec wrote:
Could you talk more about this?: "You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access."
Once the app is created you have to have some means of distributing it. If it comprises a .exe plus supporting .dlls and a rdb back end you have to get them onto the user's machine. With 'traditional' .exes there are issues with differing versions of .dlls (commonly referred to as dlHell, similar to MDAC issues. These have pretty much gone away in .Net - there's no problems with having multiple versions of the same .dll.)
copec wrote:
explain why I need toolboxes, wrappers (like wxpython)?
Strictly you don't, if you are prepared to create your own widgets such as buttons, textboxes and comboboxes to populate forms (you would have to create a widget for the form as well). If you take C++ as an example, the language itself does not provide any GUI widgets at all. So to create a GUI you need a toolbox of widgets that you can hook up to. MS Visual Studio provides such a toolbox that's available to any of the languages it supports (true even before .Net e.g. VB6 and VC++). I don't know what the wxpython wrapper does (quick Google says it's a wrapper around a widget toolkit). So it looks like if you use Python you have to make sure the wxpython wrapper plus the toolkit plus Python runtime (
-
copec wrote:
developing a truly independent program
Not sure you can develop a completely independent program. If you create an executable (i.e. .exe) it will almost certainly depend on some system .dlls - pretty much unavoidable. It will also depend on having an RDBMS (e.g. SQL Server) if you use a relational db.
copec wrote:
don't love that it is dependent on JVM
You don't need the JVM on user's machines, just the JRE - at least that's my understanding. If you use C++ to create a .Net app, user's would need the .Net framework installed. I don't know Python so don't know its dependencies.
copec wrote:
Should I not be concerned about stability or security of using something built on a platform, like JVM or .net?
These are probably concerns irrespective of platform. How critical they are depends on the nature of the app.
copec wrote:
Could you talk more about this?: "You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access."
Once the app is created you have to have some means of distributing it. If it comprises a .exe plus supporting .dlls and a rdb back end you have to get them onto the user's machine. With 'traditional' .exes there are issues with differing versions of .dlls (commonly referred to as dlHell, similar to MDAC issues. These have pretty much gone away in .Net - there's no problems with having multiple versions of the same .dll.)
copec wrote:
explain why I need toolboxes, wrappers (like wxpython)?
Strictly you don't, if you are prepared to create your own widgets such as buttons, textboxes and comboboxes to populate forms (you would have to create a widget for the form as well). If you take C++ as an example, the language itself does not provide any GUI widgets at all. So to create a GUI you need a toolbox of widgets that you can hook up to. MS Visual Studio provides such a toolbox that's available to any of the languages it supports (true even before .Net e.g. VB6 and VC++). I don't know what the wxpython wrapper does (quick Google says it's a wrapper around a widget toolkit). So it looks like if you use Python you have to make sure the wxpython wrapper plus the toolkit plus Python runtime (
Thanks again, David. I get your point about dllhell compared with Java or .net, but can't that be avoided also by using unregistered dlls? (I read that somewhere and I don't know the ramifications, I'm just throwing it out there to see what you think).
riced wrote:
So it looks like if you use Python you have to make sure the wxpython wrapper plus the toolkit plus Python runtime is installed on user machine.
Would or could this normally be done during the install of the program itself on the client machine? If I used an IDE other than VS, like say if I used an IDE for Python, like NetBeans for instance. Would I need to gather my "widget toolkits" and plug them into the IDE somehow, or how do you use them from within the IDE? Or does my question show that I don't quite understand? Thanks.
-
Thanks again, David. I get your point about dllhell compared with Java or .net, but can't that be avoided also by using unregistered dlls? (I read that somewhere and I don't know the ramifications, I'm just throwing it out there to see what you think).
riced wrote:
So it looks like if you use Python you have to make sure the wxpython wrapper plus the toolkit plus Python runtime is installed on user machine.
Would or could this normally be done during the install of the program itself on the client machine? If I used an IDE other than VS, like say if I used an IDE for Python, like NetBeans for instance. Would I need to gather my "widget toolkits" and plug them into the IDE somehow, or how do you use them from within the IDE? Or does my question show that I don't quite understand? Thanks.
You can avoid dllHell by using unregistered dlls, my point was that however you create the app there will still be a need to package its components to get them onto user machines. If the app relies on particular system components (e.g. .Net 3.5 framework, JRE or wxPython) you also need to either get them onto to the machines or abort the installation. As I said I don't know Python so cannot be specific about what is required. However, I understand Python can be used with a wide variety of toolkits and that there's a large number of IDEs that allow you to develop GUI apps. I would expect that if you download Python it will give the option of installing a toolkit. If it does not, there's likely to be some info on how to install a toolkit. Once that's done I would expect the IDE to either pick up the toolkit or allow you to hook into it. You might find that the IDE expects to find a particular toolkit installed (a quick google indicates that wxPython is the toolkit most likely to be supported). Sun was doing something to support Python in NetBeans (as of Nov 2008) but I don't know how far it's got. BTW if you use NetBeans you need to have Java installed - at least you did when I last used it (about 5 years ago). :)
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
You can avoid dllHell by using unregistered dlls, my point was that however you create the app there will still be a need to package its components to get them onto user machines. If the app relies on particular system components (e.g. .Net 3.5 framework, JRE or wxPython) you also need to either get them onto to the machines or abort the installation. As I said I don't know Python so cannot be specific about what is required. However, I understand Python can be used with a wide variety of toolkits and that there's a large number of IDEs that allow you to develop GUI apps. I would expect that if you download Python it will give the option of installing a toolkit. If it does not, there's likely to be some info on how to install a toolkit. Once that's done I would expect the IDE to either pick up the toolkit or allow you to hook into it. You might find that the IDE expects to find a particular toolkit installed (a quick google indicates that wxPython is the toolkit most likely to be supported). Sun was doing something to support Python in NetBeans (as of Nov 2008) but I don't know how far it's got. BTW if you use NetBeans you need to have Java installed - at least you did when I last used it (about 5 years ago). :)
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
Thanks for the info, David. I hadn't considered the issue of installation until now, but I see what you mean about how the user would need all necessary components to be able to run the program. At what point during development would I need to start thinking about, and planning, and taking actions for, the installation process of getting all necessary components onto an end user's machine?
-
Thanks for the info, David. I hadn't considered the issue of installation until now, but I see what you mean about how the user would need all necessary components to be able to run the program. At what point during development would I need to start thinking about, and planning, and taking actions for, the installation process of getting all necessary components onto an end user's machine?
Probably from the start. :) If you have a target set of users in mind it is worth finding out what they are likely to have installed. For example if they have .Net 2.0 it would make sense to consider build the app using that framework. There may be good reasons not to do so but then you have to look at having some installation package and the licensing conditions regarding redistribution of the components such as the run time engine (e.g. JRE if you do it in Java). If you wait until the app is in development you might find that it's difficult or impossible to actually distribute it. Ideally, you should set up (at least) two machines: one for development and one for production (i.e. to mimic users' machines). You could then install the proposed development platform, build a 'Hello World' app and try to package and install it on the production machine. This would also allow you to test various distribution channels e.g. from CD or via a download from a network.
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
Probably from the start. :) If you have a target set of users in mind it is worth finding out what they are likely to have installed. For example if they have .Net 2.0 it would make sense to consider build the app using that framework. There may be good reasons not to do so but then you have to look at having some installation package and the licensing conditions regarding redistribution of the components such as the run time engine (e.g. JRE if you do it in Java). If you wait until the app is in development you might find that it's difficult or impossible to actually distribute it. Ideally, you should set up (at least) two machines: one for development and one for production (i.e. to mimic users' machines). You could then install the proposed development platform, build a 'Hello World' app and try to package and install it on the production machine. This would also allow you to test various distribution channels e.g. from CD or via a download from a network.
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
Maybe some dumb questions here: 1) So there are licensing issues to be dealt with (money?) if I wanted to package the runtime components with the program, all to be installed by the program installer? 2) What about having the installer check for proper runtime software, and if it didn't find it (or a recent enough version), abort the install and tell the user that they need to go download and install the runtime? Maybe even have the installer launch a browser and point it to the install/download page? Is this a viable way of doing it to get around any licensing issues (if I understand what you meant above)? Thanks again for your help.
modified on Wednesday, July 15, 2009 2:20 PM
-
Maybe some dumb questions here: 1) So there are licensing issues to be dealt with (money?) if I wanted to package the runtime components with the program, all to be installed by the program installer? 2) What about having the installer check for proper runtime software, and if it didn't find it (or a recent enough version), abort the install and tell the user that they need to go download and install the runtime? Maybe even have the installer launch a browser and point it to the install/download page? Is this a viable way of doing it to get around any licensing issues (if I understand what you meant above)? Thanks again for your help.
modified on Wednesday, July 15, 2009 2:20 PM
There are possible issues with licenses. Depends on the particular software and whether you go commercial with the product. Some freely available stuff has restrictions on redistribution in commercial products. Another example, IIRC, MS Office Developer had some elements that could only be used for development. It would probably be a good idea to check for any existing runtime that the app requires. I think the installer should tell the user if any elements are missing - these should be detailed in documentation as prerequisites.
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
There are possible issues with licenses. Depends on the particular software and whether you go commercial with the product. Some freely available stuff has restrictions on redistribution in commercial products. Another example, IIRC, MS Office Developer had some elements that could only be used for development. It would probably be a good idea to check for any existing runtime that the app requires. I think the installer should tell the user if any elements are missing - these should be detailed in documentation as prerequisites.
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis
-
There are possible issues with licenses. Depends on the particular software and whether you go commercial with the product. Some freely available stuff has restrictions on redistribution in commercial products. Another example, IIRC, MS Office Developer had some elements that could only be used for development. It would probably be a good idea to check for any existing runtime that the app requires. I think the installer should tell the user if any elements are missing - these should be detailed in documentation as prerequisites.
Regards David R --------------------------------------------------------------- "Every program eventually becomes rococo, and then rubble." - Alan Perlis