|
|
10-27-2014, 11:21 AM
|
#31
|
Registered User
Join Date: Jan 2005
Posts: 6,626
|
For non-database users, the first steps are critical. Both Access and Open Office make those steps quick and easy, via wizards. Once the initial learning process (REALLY short) gets one up and running, switching to another database (at some later date) takes little more than clicking a few buttons. Both Access and Open Office are intended for new users. Both are simple, easy to use, and near perfect for learning the basics.
I would lean heavily toward Access, because as one becomes more familiar with the processes, it is extremely simple to write short VBA code blocks to make Access do whatever one wants to do.
It is well to bear in mind that the value of databases is in querying the data, not just holding it in one place. Access makes writing those queries both quick and easy. It is a perfect example of the Microsoft philosophy of writing user-friendly apps that make it easy for new users to get started, and to enable them to do fairly complex stuff in a relatively short period of time.
Last edited by traynor; 10-27-2014 at 11:23 AM.
|
|
|
10-27-2014, 11:23 AM
|
#32
|
Screw PC
Join Date: Jun 2003
Posts: 15,728
|
Quote:
Originally Posted by Tom
DJ....can OO open Acess DB files?
|
It appears it can -- however, I do not have Access (any more) so I can not test it to confirm.
See: https://www.openoffice.org/FAQs/ms-a...ms-access.html
__________________
Truth sounds like hate to those who hate truth.
|
|
|
10-27-2014, 11:33 AM
|
#33
|
Screw PC
Join Date: Jun 2003
Posts: 15,728
|
Quote:
Originally Posted by traynor
For non-database users, the first steps are critical. Both Access and Open Office make those steps quick and easy, via wizards. Once the initial learning process (REALLY short) gets one up and running, switching to another database (at some later date) takes little more than clicking a few buttons. Both Access and Open Office are intended for new users. Both are simple, easy to use, and near perfect for learning the basics.
I would lean heavily toward Access, because as one becomes more familiar with the processes, it is extremely simple to write short VBA code blocks to make Access do whatever one wants to do.
It is well to bear in mind that the value of databases is in querying the data, not just holding it in one place. Access makes writing those queries both quick and easy. It is a perfect example of the Microsoft philosophy of writing user-friendly apps that make it easy for new users to get started, and to enable them to do fairly complex stuff in a relatively short period of time.
|
I can not disagree with anything you've said. However, I think it needs to be said that beyond the power gained vis-a-vie the query engine, it only will be capable of fulfilling that promise if the database and the tables making up the database are well formed. So, learning a bit about normal forms and what joins are will help get things off on the right foot. The wrong foot could very well mean your data is in a database but you can't use it for anything meaningful.
A long time ago, back when Paradox with the RDBMS I was using, the nice thing it offered was QBE, query by example. It allowed you to form queries by checking boxes (and a few other things) which shielded you from having to learn SQL. It help flatten the learning curve. I don't know if anything like QBE is around any more but it was what I thought of when I tried OO Base the first time.
__________________
Truth sounds like hate to those who hate truth.
Last edited by DJofSD; 10-27-2014 at 11:34 AM.
|
|
|
10-27-2014, 11:33 AM
|
#34
|
Registered User
Join Date: Jun 2011
Posts: 588
|
In terms of flexibility and level of complexity for queries, access and other database programs are no match for excel in my opinion. That being said, it would probably prove more challenging to set up a basic database in Excel than access for most people. In my program I can write formulas and macros to do anything I can think of and processing speed is only a minor issue when looking at individual tracks. I would not recommend mixing every track and year you have and then doing a 50000 race query, it will amount to nothing useful. It is better to focus on an individual track and then be as creative as possible with the queries. Of course it may take a long time before you generate enough experience to find something of value, and you will have to start off slow and very basic but this type of thing requires a lot of work, there is no question.
|
|
|
10-27-2014, 11:52 AM
|
#35
|
Registered User
Join Date: Jan 2005
Posts: 6,626
|
Simply storing data is like having a stack of DRF back issues. There might be something useful there, but finding it takes more than the cardboard box they are stored in. It is in the querying process that "new and useful insights" are gained, not in the storing process.
Once the data is in Access, it is fairly simple to extract blocks of code with simple queries (all created with the help of the friendly Microsoft wizards) and run them through a secondary app like WEKA or Anaconda 3 (for data mining). Those apps will generate stuff out of the box that would take immense amounts of time to code in SQL (or JSON, or whatever else)--that also requires one be knowledgeable enough to know up front what he or she is looking for, and exactly what processes will uncover that information.
Learning to use Access or Open Office is simple. They also make it simple (by providing structured data clumps) to use apps like WEKA and Anaconda 3--either of which will crank out more statistical analyses of that data in seconds than anyone really wants or needs. All with a few button clicks.
Last edited by traynor; 10-27-2014 at 11:56 AM.
|
|
|
10-27-2014, 12:10 PM
|
#36
|
EXCEL with SUPERFECTAS
Join Date: Mar 2004
Posts: 10,206
|
Quote:
Originally Posted by JJMartin
In terms of flexibility and level of complexity for queries, access and other database programs are no match for excel in my opinion. That being said, it would probably prove more challenging to set up a basic database in Excel than access for most people. In my program I can write formulas and macros to do anything I can think of and processing speed is only a minor issue when looking at individual tracks. I would not recommend mixing every track and year you have and then doing a 50000 race query, it will amount to nothing useful. It is better to focus on an individual track and then be as creative as possible with the queries. Of course it may take a long time before you generate enough experience to find something of value, and you will have to start off slow and very basic but this type of thing requires a lot of work, there is no question.
|
I agree, Excel was/is much easier to use, for me. One flat file with no need for normalization, keys, SQL, etc., make it very easy for an intermediate Excel user to get it going. There were a few attempts on this forum to create Access racing databases, and to my knowledge none of them got off the ground. Part of that failure could be that those who really understand database creation seem to feel that giving away that knowledge, or actively participating in the creation, is taboo.
For instance, for someone who really knows database creation in Access, using Brisnet data files, and there are many here, how hard would it be to post the tables, complete, and some basic queries already included, from which others could simply modify those queries to meet their own needs? I never did understand why that has never happened. It's almost like the DB guys only want to associate with other DB guys, and if you don't already know all that stuff they don't want to talk to you, in layman's language that you can understand, without doing a lot of reading and studying about databases (which I have already done and could not understand enough to implement).
There appears to be lots of talk, and little usable substance, regarding database creation and use here. if it's so easy, then why not just post it? Or, do you want new users to have to jump through all the hoops that you went through? That's rather obtuse , in my opinion, this coming from someone who has always offered help to anyone wanting it. I guess there just aren't that many people who really want to help people.
Last edited by raybo; 10-27-2014 at 12:18 PM.
|
|
|
10-27-2014, 12:40 PM
|
#37
|
Registered User
Join Date: Feb 2003
Posts: 2,105
|
Quote:
Originally Posted by raybo
I agree, Excel was/is much easier to use, for me. One flat file with no need for normalization, keys, SQL, etc., make it very easy for an intermediate Excel user to get it going. There were a few attempts on this forum to create Access racing databases, and to my knowledge none of them got off the ground. Part of that failure could be that those who really understand database creation seem to feel that giving away that knowledge, or actively participating in the creation, is taboo.
|
At least two of us offered to help classhandicapper should he need it.
When you say "why not just post it" you misunderstand the potential scope of an Access program.
Mine has many hundreds of objects and just to look at it would not allow the viewer any idea what is under the hood.
Plus who would post something that took thousands of hours of development particularly when it would lose its edge with copycat players.
To say nothing of the gross terms of service violation for the data within.
|
|
|
10-27-2014, 12:47 PM
|
#38
|
EXCEL with SUPERFECTAS
Join Date: Mar 2004
Posts: 10,206
|
Quote:
Originally Posted by sjk
At least two of us offered to help classhandicapper should he need it.
When you say "why not just post it" you misunderstand the potential scope of an Access program.
Mine has many hundreds of objects and just to look at it would not allow the viewer any idea what is under the hood.
Plus who would post something that took thousands of hours of development particularly when it would lose its edge with copycat players.
To say nothing of the gross terms of service violation for the data within.
|
I guess I'm just a dummy then, for having posted complete workbooks, with all the macros and data in them, to say nothing of the thousands of hours of sweat and tears that came before them. Call the TOS cops, I don't care.
|
|
|
10-27-2014, 01:45 PM
|
#39
|
The Voice of Reason!
Join Date: Mar 2001
Location: Canandaigua, New york
Posts: 112,983
|
You would have to post the Access program, and that is not possible. It is not like a spreadsheet one can post and someone can then open. If I just posted the table and a query, you would need to know how to import them into your own program and then open and use them. If you want to try it, I will post a BRIS db, text file input, and a query for you to try out.
What I like best about Access is it is easy to take data from several sources and merge only applicable lines from each into a new output.
Once I run a query, I can work with the results in Excel by simply opening it in Excel. I do the grunt work in Excel and the storage, merging in Access.
__________________
Who does the Racing Form Detective like in this one?
|
|
|
10-27-2014, 02:16 PM
|
#40
|
Registered User
Join Date: Nov 2005
Posts: 1,084
|
Quote:
Originally Posted by traynor
Simply storing data is like having a stack of DRF back issues. There might be something useful there, but finding it takes more than the cardboard box they are stored in. It is in the querying process that "new and useful insights" are gained, not in the storing process.
Once the data is in Access, it is fairly simple to extract blocks of code with simple queries (all created with the help of the friendly Microsoft wizards) and run them through a secondary app like WEKA or Anaconda 3 (for data mining). Those apps will generate stuff out of the box that would take immense amounts of time to code in SQL (or JSON, or whatever else)--that also requires one be knowledgeable enough to know up front what he or she is looking for, and exactly what processes will uncover that information.
Learning to use Access or Open Office is simple. They also make it simple (by providing structured data clumps) to use apps like WEKA and Anaconda 3--either of which will crank out more statistical analyses of that data in seconds than anyone really wants or needs. All with a few button clicks.
|
Thanks for posting.
I'll have to look at WEKA and Anaconda 3.
|
|
|
10-27-2014, 02:33 PM
|
#41
|
Registered User
Join Date: Mar 2005
Location: Queens, NY
Posts: 20,662
|
Well, I have the software installed and I'm watching tutorial videos on youtube. Shouldn't be long before I start pulling out whatever hair I have left.
__________________
"Unlearning is the highest form of learning"
|
|
|
10-27-2014, 02:57 PM
|
#42
|
Registered User
Join Date: Jan 2005
Posts: 6,626
|
Quote:
Originally Posted by Exotic1
Thanks for posting.
I'll have to look at WEKA and Anaconda 3.
|
YouTube has a set of WEKA tutorials (basic intro) by the professor who teaches it in New Zealand. In a couple of hours you can learn more about data mining than most college students learn in a year--and have the skills to use that knowledge. I would also recommend looking into RapidMiner as an app (it is great!) but the tutorials for RapidMiner on YouTube are not too good.
|
|
|
10-27-2014, 03:28 PM
|
#43
|
Registered User
Join Date: Nov 2005
Posts: 1,084
|
Quote:
Originally Posted by traynor
YouTube has a set of WEKA tutorials (basic intro) by the professor who teaches it in New Zealand. In a couple of hours you can learn more about data mining than most college students learn in a year--and have the skills to use that knowledge. I would also recommend looking into RapidMiner as an app (it is great!) but the tutorials for RapidMiner on YouTube are not too good.
|
|
|
|
10-27-2014, 03:51 PM
|
#44
|
EXCEL with SUPERFECTAS
Join Date: Mar 2004
Posts: 10,206
|
Quote:
Originally Posted by classhandicapper
Well, I have the software installed and I'm watching tutorial videos on youtube. Shouldn't be long before I start pulling out whatever hair I have left.
|
Good luck! I hope you have more luck than I did.
I studied a book on relational databases, and another on SQL, both were about 4" thick, and neither explained things to where I could understand them. A complete waste of time.
Last edited by raybo; 10-27-2014 at 03:52 PM.
|
|
|
10-27-2014, 04:21 PM
|
#45
|
Registered User
Join Date: Mar 2005
Location: Queens, NY
Posts: 20,662
|
I downloaded the Nov 1 Breeder's Cup files out of Formulator.
A few questions came up immediately.
1. I can download all the Formulator data for that card as one file or multiple files. If I download it as one file, I will have multiple record types of different lengths that contain different fields and data. So I can't see how I can import that single file into a single database without causing a total mess. It seems like I will have to download the Formulator data as separate files and import them into separate databases. Does that seem correct?
2. The major file is a horse file. It contains a header record that describes what each field contains and then hundreds of data records. is there any way of importing that header record and making those my field names so I don't have to manually type all those field names in myself?
Other than that, the import of that single file took a few seconds.
__________________
"Unlearning is the highest form of learning"
|
|
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|