Aquaculture software
- Thread starter NicoleC
- Start date
marinebetta
Premium Member
Great idea, Nicole. I would go for it!
For us simple folk, an easy to use user interface is important - don't really care what goes on in the back end; wouldn't understand most of it anyway
so long as it's easy to fill in and pull out info at the end of the day.
Would the fact that clowns change sex come into play at all in your ID system?...the daddy becomes a mommy in another pairing
...and...any chance it can be converted into palm format
For us simple folk, an easy to use user interface is important - don't really care what goes on in the back end; wouldn't understand most of it anyway
so long as it's easy to fill in and pull out info at the end of the day.Would the fact that clowns change sex come into play at all in your ID system?...the daddy becomes a mommy in another pairing
...and...any chance it can be converted into palm format
NicoleC
New member
Okay, first, the discussion of VB.NET is regarding a hypothetical web version. I am not totally adverse to a web solution, but a) I am not spending my own money on this and b) I am not getting sucked into a project that will require me doing daily maintenance and tech support indefinately. Finally, should I tire of the project, some using a web version will lose all their data and the tool. Bummer.
If someone can solve all those issues for me, the web software discussion can resume.
Assuming not, we are talking about a standalone software piece in VB/VBA using Access as a front-end tool.
Richard, you're losing me; I don't get what you are talking about with attaching things to a timeline. Are you suggest a tiered DB structure with the tank as the top level entity?
Steve, what exactly do you mean by "locationID"? Is the a primary key? A foreign key to a hypothetic master database of all users?
Jay, I usually separate frontend and backend. For the sake of simplicity here, I wasn't going to do that because it will make it easier to deploy, but it's worth considering. Heck, I may go entirely with unbound forms and set everything web-style.
Okay, we have two different use cases emerging.
The first, which was my original idea, was to track fish and batches of larvae, somewhat along the lines of a pedigree software package with the necessary bits of care info built in. The goal of the software was to improve breeding practices. The concept of tanks was just to keep track of water volume, etc., but could have been used to specific a location of a particular breeding pair of spawn.
The second use case scenario is emerging from Jay (and Richard?), who maybe feel like they have the breeding thing down better and are more concerned with needing to know what they need to do for each tank each day.
If I put on my thinking cap, I should be able to come up with a DB structure that accomodates both but the front ends will by necessity be need to be different. (Two sections of the same application.)
For those interested in a tank-based model, how is this different from TankMinder, ReefCon200, AquaLog, etc.?
If someone can solve all those issues for me, the web software discussion can resume.
Assuming not, we are talking about a standalone software piece in VB/VBA using Access as a front-end tool.
Richard, you're losing me; I don't get what you are talking about with attaching things to a timeline. Are you suggest a tiered DB structure with the tank as the top level entity?
Steve, what exactly do you mean by "locationID"? Is the a primary key? A foreign key to a hypothetic master database of all users?
Jay, I usually separate frontend and backend. For the sake of simplicity here, I wasn't going to do that because it will make it easier to deploy, but it's worth considering. Heck, I may go entirely with unbound forms and set everything web-style.
Okay, we have two different use cases emerging.
The first, which was my original idea, was to track fish and batches of larvae, somewhat along the lines of a pedigree software package with the necessary bits of care info built in. The goal of the software was to improve breeding practices. The concept of tanks was just to keep track of water volume, etc., but could have been used to specific a location of a particular breeding pair of spawn.
The second use case scenario is emerging from Jay (and Richard?), who maybe feel like they have the breeding thing down better and are more concerned with needing to know what they need to do for each tank each day.
If I put on my thinking cap, I should be able to come up with a DB structure that accomodates both but the front ends will by necessity be need to be different. (Two sections of the same application.)
For those interested in a tank-based model, how is this different from TankMinder, ReefCon200, AquaLog, etc.?
NicoleC
New member
For us simple folk, an easy to use user interface is important - don't really care what goes on in the back end; wouldn't understand most of it anyway
Yes, must. For me too -- I mean I may program the stuff, but I still don't want to have to sit there and tinker with it when I trying to USE it!
Would the fact that clowns change sex come into play at all in your ID system?...the daddy becomes a mommy in another pairing
Fish are fish, they are an entity same as any other. If we can have 3-somes and 4-somes, sex won't be a critical factor
...and...any chance it can be converted into palm format
That's funny, I had a dream last night that you could use wirelessly connected Palms Pilots to enter data while standing at the tanks, then you could sit down at the desktop to run reports and compare data.
Yeah... that may be a bit beyond the scope of this application
As far as the tank based model... I'm mostly interested in knowing what I 'have' done as opposed to what I need to do (though, I do use the latter too, especially when I'm out of town as mentioned).
For instance, I'm interested in knowing how much of any given types of food I've fed to whatever tanks. The idea is that long term this information coupled with the amount of fish I'm hatching every week + the amount of fish I'm selling every week (assuming I'm selling everything I'm hatching/raising out) can start to give me an idea of survival rates and growth rates on different feed/care regimines. So... sort of a cross between both use cases you've defined.
Once I know that, then things like forcasting sales, planing for growth of systems and making my systems/methods better and more efficient fall into line.
(I really like the fact that I refer to things like 'sales' as if I'm actually making money at this! *chuckles* Don't I wish.)
For instance, I'm interested in knowing how much of any given types of food I've fed to whatever tanks. The idea is that long term this information coupled with the amount of fish I'm hatching every week + the amount of fish I'm selling every week (assuming I'm selling everything I'm hatching/raising out) can start to give me an idea of survival rates and growth rates on different feed/care regimines. So... sort of a cross between both use cases you've defined.
Once I know that, then things like forcasting sales, planing for growth of systems and making my systems/methods better and more efficient fall into line.
(I really like the fact that I refer to things like 'sales' as if I'm actually making money at this! *chuckles* Don't I wish.)
OH sorry I forgot to mention... quick note. I have an internet facing web server with a seperate sql server available if you need space/resources for this project. I can set you up a remote desktop/etc as well if needed for local access to these resources. Anything I can do, let me know.
mwp
In Memoriam
Nicole, FWIW I'm using an Excel spreadsheet to track my tanks - charts things like water parameters, etc...I mark rows by days and time and also have a section for comments (plus all the columns for water parameters). It's downside is that it's hard to track a specific spawning event or look it up; the upside is perhaps all the graphing from the data (i.e. lets me notice trends in calcium levels, temp etc...)
FWIW,
Matt
FWIW,
Matt
NicoleC
New member
Jay, I have a domain and SQL Server I use as a sandbox, but I'm thinking long term. A web app requires a long term infrastructure that I am not willing to commit to.
On the use case issue, as long as livestock can be split and merged into tanks, that will work from a model based around a livestock entity. Those who want tank detail will be able to access it, those who don't can just use generic tank info to track parameters.
Rough DB structure coming up (for the technically inclined.)
On the use case issue, as long as livestock can be split and merged into tanks, that will work from a model based around a livestock entity. Those who want tank detail will be able to access it, those who don't can just use generic tank info to track parameters.
Rough DB structure coming up (for the technically inclined.)
NicoleC
New member
Okay, here's the DB model. Not all the fields are in place, of course, but it shows the relationships. Highly normalized recursive designs will give you a headache to try to visualize, but it's the only structure that I think will work for ALL the items.
BTW, on the note about calendar items, that doesn't mean ONLY milestones can be made to go on a calendar. Just that you can set items to show up on calendars by default.
There are a few tables missing already -- for example, a nutrition table where you can store a list of food items you commonly use so they populate a dropdrop box for quick selection (or something like that), but since they don't relate to the other tables, I left them off.
Enjoy.
BTW, on the note about calendar items, that doesn't mean ONLY milestones can be made to go on a calendar. Just that you can set items to show up on calendars by default.
There are a few tables missing already -- for example, a nutrition table where you can store a list of food items you commonly use so they populate a dropdrop box for quick selection (or something like that), but since they don't relate to the other tables, I left them off.
Enjoy.
spk
Premium Member
Nicole,
Sorry for the late reply. With regard to the LocationID. I was thinking along the lines of the ability to share data between people. You would need to have a way to identify the source of information.
Say for instance, you were populating your db with data, and perhaps I was populating mine, we could then share our data with each other and upon inport a new ID is created that allows us to have two seperate sets of data that we can look at.
It basically means that we can see what others are doing and keep it seperate with out having multiple DB.
Perhaps the other way is to allow the app to open a different data base rather than go through the whole hassel of structung the db to allow for multiple id's Yes that sounds a lot easier.
Your DB structure looks great.
Steve
Sorry for the late reply. With regard to the LocationID. I was thinking along the lines of the ability to share data between people. You would need to have a way to identify the source of information.
Say for instance, you were populating your db with data, and perhaps I was populating mine, we could then share our data with each other and upon inport a new ID is created that allows us to have two seperate sets of data that we can look at.
It basically means that we can see what others are doing and keep it seperate with out having multiple DB.
Perhaps the other way is to allow the app to open a different data base rather than go through the whole hassel of structung the db to allow for multiple id's Yes that sounds a lot easier.
Your DB structure looks great.
Steve
NicoleC
New member
Sending a copy of a whole database will include all your tanks, customization, costs of supplies, etc. I wouldn't want that, would you?
Export/import doesn't need to be a hassle if designed properly. But I think sharing electronic data should be tabled until there's a program to put data IN.
The most common item I can think of to share are a data file that summarizes a fish, for example if I buy a fish from Morgman and want to breed it, I might want to attach a record of hatch date, etc. instead of retyping it all.
Otherwise, I might want to share a report of a batch's progress or some other static report, which will really be to complex to send from one stand alone application to another. Of course, the export could be in Excel or a text file or even XML, and that could be used by almost any other program that wants to deal with parsing out the info -- for example if someone wanted to host a site that shared/compared breeding reports.
Export/import doesn't need to be a hassle if designed properly. But I think sharing electronic data should be tabled until there's a program to put data IN.
The most common item I can think of to share are a data file that summarizes a fish, for example if I buy a fish from Morgman and want to breed it, I might want to attach a record of hatch date, etc. instead of retyping it all.
Otherwise, I might want to share a report of a batch's progress or some other static report, which will really be to complex to send from one stand alone application to another. Of course, the export could be in Excel or a text file or even XML, and that could be used by almost any other program that wants to deal with parsing out the info -- for example if someone wanted to host a site that shared/compared breeding reports.
Coraldynamics
In Memoriam
Nicole, would having a webserver you don't have to maintain help you out "in case you tire of the project" then the info would not be lost. I can provide the webspace via my non-commercial website (reefobsession.com) It currently houses the Clownfish Surveys and Eric Borneman's Elegance Coral Project stuff.
It does have access to a SQL database server (surveys use it)
Thoughts, concerns? I was planning on moving the surveys to another server but have been putting it off. So I can continue to put it off for a while.
It does have access to a SQL database server (surveys use it)
Thoughts, concerns? I was planning on moving the surveys to another server but have been putting it off. So I can continue to put it off for a while.
NicoleC
New member
Well, guys, Stephen has made a geneous offer, so I will put it to a vote. As you may have figured out, my preference is for a stand-alone app. I like web apps, but I don't think they are a good choice in this situation. I will probably not use any web app for this and will build a simpler desktop version for my own use, but I am willing to spend some dev time on a community project.
Here's the pros and cons:
Standalone app PROS
*Development time is faster. I can have a functioning beta version up in about a month. ETA 3 months for a preliminary, reduced function web version to be in beta.
*Your data is private, and you share only what you choose and with whom
*Your have access to your data on your own computer anytime. With a web app, you must be connected to the internet to add, change or view any records
*You can continue to use the software indefinately, even if support is withdrawn for the web site or software changes
*You can choose not to upgrade if you don't want to
Web app PROS
*Easier to share development, if person/people will commit to helping
*Immune to local computer crashes; backups are made on the server level (one hopes; you won't know for sure)
*Works on any computer with an internet connection and compatible browser
*Upgrades are immediate and easier, including changes to backend DB design, although it will require downtime
*Live data can be made available for public view
Here's the pros and cons:
Standalone app PROS
*Development time is faster. I can have a functioning beta version up in about a month. ETA 3 months for a preliminary, reduced function web version to be in beta.
*Your data is private, and you share only what you choose and with whom
*Your have access to your data on your own computer anytime. With a web app, you must be connected to the internet to add, change or view any records
*You can continue to use the software indefinately, even if support is withdrawn for the web site or software changes
*You can choose not to upgrade if you don't want to
Web app PROS
*Easier to share development, if person/people will commit to helping
*Immune to local computer crashes; backups are made on the server level (one hopes; you won't know for sure)
*Works on any computer with an internet connection and compatible browser
*Upgrades are immediate and easier, including changes to backend DB design, although it will require downtime
*Live data can be made available for public view
Morgman
New member
Nicole-
I think something that would be interesting about your previous idea would be have some type of linage certificate much like the AKC does for dogs.
In other words, a type of paper(or digital) that gives customers or end users some idea(as accurate as one can be) to where their fish came from and its generations of CB etc. Then ten or 20 years down the road some breeders may have some pretty deep lineages of generations of CB intermixed with wild caught species. So when they get their clowns they can say hey look the great grandparents of this clown came from ORA broodstock in the 90s that was breed with this xx clowns for 15 years etc etc.
I know this is obviously a hard thing to do in the real world.
I think something that would be interesting about your previous idea would be have some type of linage certificate much like the AKC does for dogs.
In other words, a type of paper(or digital) that gives customers or end users some idea(as accurate as one can be) to where their fish came from and its generations of CB etc. Then ten or 20 years down the road some breeders may have some pretty deep lineages of generations of CB intermixed with wild caught species. So when they get their clowns they can say hey look the great grandparents of this clown came from ORA broodstock in the 90s that was breed with this xx clowns for 15 years etc etc.
I know this is obviously a hard thing to do in the real world.
NicoleC
New member
I won't be hard within the application itself and the DB structure supports it as outline above to infinite generations.
However, some sort of centralized registration organization would be required for it all to work together. I can just see it now... my female clown is "Nicole's Tangerine Janice" and the male is "Nemo's Adventure Jimmy."
Right now it's not critical, but someday when species' start getting banned from wild capture, it would certainly help produce healthy pairings to know how closely related and inbred certain fish are, or to use line breeding to produce new colors/patterns.
However, some sort of centralized registration organization would be required for it all to work together. I can just see it now... my female clown is "Nicole's Tangerine Janice" and the male is "Nemo's Adventure Jimmy."
Right now it's not critical, but someday when species' start getting banned from wild capture, it would certainly help produce healthy pairings to know how closely related and inbred certain fish are, or to use line breeding to produce new colors/patterns.
rsman
New member
I know "here he goes being a problem AGAIN" well :wildone: :crazy1: why not both
though for this scale i suspect that at least a few of the con's for the web one will not really be a problem. i also see some of the con's for the desktop version not being a problem either
will I use it, donno, might, ive got a LOT of records to convert, but i just might consider it, how much will I make public, probibly all of it as i dont need to hide my secrets from my neighbors
i dont understand you say a month to release a beta does that mean you have some kinda life or job ????
as I run quickly and far for cover
if your into doubling up the efforts I wont mind doing the web work to have a beta out in a month ish, assuming we can come up with a data structure that we can agree on, and features we can impliment in both in a beta release.
as for privacy I see it as a 2 part thing, users who used the web one would have to trust those that set it up that the information they desired to keep private was kept private, but a simple check for private box seems to work for me ???
the structure I see starts with a 2 part key a date and a system description, the date would be the date it started, then as tanks/filters .... were changed they would be added in another table [tanks] and [filters] with descriptions and dates as the PK then from there you have a [breedingfish] with date and tank as the PK if you moved the fish then a new record would be started using the origional fish and a new tank, then other tables for things like larva, rearing, growout and food sources and such.
this establishes a timeline, the timeline itself would have to be handled in SW not the DB but will be easy to impliment in either. you just start at the top "system" and filter down to whatever was connected to it. selecting all of the filters connected to system, then all the tanks, a "end date" field would signial that the tank was to stop at some point on the timeline.
i started a visio thing on it, but while i dont have a life i am stuck at work
so my play time is limited.
though for this scale i suspect that at least a few of the con's for the web one will not really be a problem. i also see some of the con's for the desktop version not being a problem either
will I use it, donno, might, ive got a LOT of records to convert, but i just might consider it, how much will I make public, probibly all of it as i dont need to hide my secrets from my neighbors
i dont understand you say a month to release a beta does that mean you have some kinda life or job ????
as I run quickly and far for cover
if your into doubling up the efforts I wont mind doing the web work to have a beta out in a month ish, assuming we can come up with a data structure that we can agree on
, and features we can impliment in both in a beta release.as for privacy I see it as a 2 part thing, users who used the web one would have to trust those that set it up that the information they desired to keep private was kept private, but a simple check for private box seems to work for me ???
the structure I see starts with a 2 part key a date and a system description, the date would be the date it started, then as tanks/filters .... were changed they would be added in another table [tanks] and [filters] with descriptions and dates as the PK then from there you have a [breedingfish] with date and tank as the PK if you moved the fish then a new record would be started using the origional fish and a new tank, then other tables for things like larva, rearing, growout and food sources and such.
this establishes a timeline, the timeline itself would have to be handled in SW not the DB but will be easy to impliment in either. you just start at the top "system" and filter down to whatever was connected to it. selecting all of the filters connected to system, then all the tanks, a "end date" field would signial that the tank was to stop at some point on the timeline.
i started a visio thing on it, but while i dont have a life i am stuck at work
so my play time is limited.
NicoleC
New member
Do the Visio thing when you have a chance, Richard. What I visualize from your text doesn't support a lot of basic items and involves a lot of redundant data, and someone already wrote that application and called it "Microsoft Project," -- so maybe I'm failing to adequately interpret your vision.
Similar threads
