Thoughts on if this database would be too hard for me (newbie) to do?

[Jack]

I'm a newbie, and while I wouldn't mind learning access at some point,
for now I need it for one purpose, which takes precedence time-wise. I
trade stocks (futures, actually), and would like to go back and track
how (we'll use stock for this purpose) behaved each day at the open. I
wouldn't mind spending some time on it; just not an inordinant amount.

Let me explain my purpose: A stock may "gap up" or "gap down", meaning
it's price opens at a price different from where it closed the day
before. Often that gap will be filled, meaning the price will go back
down (if it was a gap up) to the previous day's close. I want to track
how often it did that, how often it went only 1/2 way, how much it
went up before doing it, what day of the week it was, etc., with
several different criteria

I had started to compile it in excel, but quickly had an AHA moment
and realized this was a database I needed. Here are the categories I
have that I want to track, and then be able to search based on several
criteria. I imagine I want to creat several different tables, but it
seems to me the hardest part, and hardest to learn, is how I want it
organized. Which categories in which/how many tables. Is this more
daunting than I initially imagined (which was thinking it wouldn't
take long). Here are the categories:

DATE AMOUNT OF GAP UP DOWN % Filled Minutes it took
to Fill How Much Up before Filling, etc., etc.

I hope that's clear. TIA!

 

[Jeff Boyce]

Jack

If you want to get the best use of a relational database like Access, you
have to feed it well-normalized data. If you are not familiar with
"normalization" or "relational database", you have a steep learning curve.

If you already have experience working in Excel, remember that any list of
information is a 'database'. If you don't have the time to learn Access
right now, why not stick with something you know?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Jack]

Jack

If you want to get the best use of a relational database like Access, you
have to feed it well-normalized data. If you are not familiar with
"normalization" or "relational database", you have a steep learning curve.

If you already have experience working in Excel, remember that any list of
information is a 'database'. If you don't have the time to learn Access
right now, why not stick with something you know?

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for the feedback. I didn't finish compiling the info in excel,
as I realized that it wasn't going to provide me with all the info I'd
like. And for the same reason why I don't just do it in excel; that it
doesn't really give me the info I'd like, save for maybe an average of
a column, and number of times it filled on a Monday, or Tuesday. But
that's when I stopped with my compiling in excel, when I realized I'd
like to know, "On Mondays, when the gap was >50 points, and the open
was.... How much of the gap got filled?" Clearly, unless I create
separate worksheets in excel for each scenario, this wouldn't be
possible to find out. Hence, here I am! So, apparently it's a lot
harder than I imagined. Thanks again. Any suggestion on a place/book,
should I decide to take it on, for figuring out how I should have it
organzied? I've found some "how-to's" of creating tables, and the
basics of access, but I'm at a loss as to how I need to best organize
the data: how many/which data sets, per table, etc.
Thanks again.

 

[Jeff Boyce]

Jack

There are a huge number of books written on how-to do Access databases.
Your best bet is to visit your friendly local bookstore and start browsing
to see which one(s) writing style matches your learning style.

I remind folks that there's at least three learning curves to get past to
build applications in Access:

1. normalization and relational database design
2. Access tips/tricks (i.e., how Access does it)
3. Graphical user interface design (what works for humans)

and if you haven't created applications before, you have a fourth one:

4. Application development process

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Jack]

Thanks. I'm on #1! And I think I have the mindset for it; just hope
that it's not more than I want to chew. I checked my local library,
and was going to go tomorrow to check them out, but for my limited
purpose, I was thinking a "for dummies" would be applicable, and the
traditional tomes would be overkill. Got some good tips in another
thread, including a pointer to a good video that explaned normalizing
data. And hopefully #3 won't be much of an issue, since it's just for
my own use. Thanks again.

 

[Jeff Boyce]

Jack

A decent user interface can help save YOU from making mistakes, and will
prove invaluable six months from now when you don't remember what/how <g>!

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Fred]

Jack,

A couple of note son top of the excellent advice already given.

Access will take some time to learn; you have to decided whether or not you
want to make that investment. For me the answer is yes....it is very power
and versatile software for handling information. But you have to decide for
your self. Your first post sounded like "no" and yuoru later posts sounded
like "yes".

In parallel with your learning Access, you might also want to be thinkiing
on what the entities are in your application and how they are related. Think
of "lists" and lists that can be linked together. Almost certainly
individual stocks will be such entities / lists. Beyond that is not clear.
It might be instances of "moves" of stocks, it might be instances of
recording the value of a stock at a time. Preferably you might be importing
tablular data from an external source (so that you aren't spending all day
entering minute by minute data.