![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
So, while thinking about OpenAssess.WI (as I would call the system, if I ever actually made it), I thought sqlite may be the solution, as it's small, portable, and is more like Access than an SQL server. That is, to set it up would be damn easy to do. Just bundle the dll with the app, and it's all there. It appears, from what I recall, that all it does is store the data in a text file. I like that. Simple and small.
However, according to the mono site, all the data typing is removed. Apparently sqlite only stores the data as a string. TBH, I'm not sure what that means in terms of dealing with the data. Do other databases store data-type info along with the string of data? I'd assume that as long as YOU know what you're dealing with in each field it doesn't matter, but it may be a bit more work as a developer to work with SQLite in this regards than, say, MySQL.
Thinking about the system, there's a lot of components that would be required to be dealt with (especially if one is to make it as feature filled as the competition):
1) Interface: Ideally, I'd like to have an extensible UI that allows a person to customize it. I'm thinking, in this regards, the ability to have a config file that would allow a person to "skin" the interface in a way that mimics "the competition". That is, if they are familiar with the other software, they can quickly translate over to OpenAssess. For an example, in one program we use, I manually type in the codes defined by the state: AB1 or AD2 (a flat barn or dairy barn), AP1 (a pole shed), RG1 (residential detached garage). Another program I use actually uses all numerical codes: 12-1 (in fact, two fields, 12 is in the first field denoting the AB part, and 1 is the 1), 17-1, 30-1 and 1-1 (and yes, I have a majority of these codes memorized) While on the one hand, the numerical system is more a pain in the sense it requires more memorization (and the fact that these codes don't always match up with what the state defines ... grrr), it's much faster to type 3 digits on a keypad than it is to lift up to the keyboard and switch between numbers and letters. However, different people probably feel differently. Hence, IMO, it would be nice for this "skinning" feature. The default system would of course, be the preferred/supported system, but if someone adds on and wants to share/support it, they should be free to do so.
( more design info here... )
However, according to the mono site, all the data typing is removed. Apparently sqlite only stores the data as a string. TBH, I'm not sure what that means in terms of dealing with the data. Do other databases store data-type info along with the string of data? I'd assume that as long as YOU know what you're dealing with in each field it doesn't matter, but it may be a bit more work as a developer to work with SQLite in this regards than, say, MySQL.
Thinking about the system, there's a lot of components that would be required to be dealt with (especially if one is to make it as feature filled as the competition):
1) Interface: Ideally, I'd like to have an extensible UI that allows a person to customize it. I'm thinking, in this regards, the ability to have a config file that would allow a person to "skin" the interface in a way that mimics "the competition". That is, if they are familiar with the other software, they can quickly translate over to OpenAssess. For an example, in one program we use, I manually type in the codes defined by the state: AB1 or AD2 (a flat barn or dairy barn), AP1 (a pole shed), RG1 (residential detached garage). Another program I use actually uses all numerical codes: 12-1 (in fact, two fields, 12 is in the first field denoting the AB part, and 1 is the 1), 17-1, 30-1 and 1-1 (and yes, I have a majority of these codes memorized) While on the one hand, the numerical system is more a pain in the sense it requires more memorization (and the fact that these codes don't always match up with what the state defines ... grrr), it's much faster to type 3 digits on a keypad than it is to lift up to the keyboard and switch between numbers and letters. However, different people probably feel differently. Hence, IMO, it would be nice for this "skinning" feature. The default system would of course, be the preferred/supported system, but if someone adds on and wants to share/support it, they should be free to do so.
( more design info here... )
Tags:
