Some OOTP 7 news

[jarmenia]

Originally Posted by DaveHorn

I assume the database is proprietary. Even we had ODBC access the first thing I would do is write my own dump so I can put it in a database of my choice.

Your still going to have to do that since his dump won't be in the format your looking for and that was kind of my point. Allow the individual developers to extract only the data they want/need and its simpler when using the utility as you wouldn't have to exprt first to get the most updated data as it would just read it right from the DB.

[DaveHorn]

There a a few different standards for a "SQL Dump" will Markus do a standard or his own thing? Who knows? If Markus uses a standard, little to no work will be required. If he makes his own thing, a data scrubber is a piece of cake. If I have to write a data scrubber, I'd rather go against straight text files than talk to a proprietary DB through an ODBC connection or any sort of ODBC bridge. I want all the data all the time. Third party tools such as BOSI and CATO use their own schema for a good reason. They are designed to do different things and have different needs. They need all the data all the time. I don't care what is new and what isn't new. Besides the only way to get updated data was if every single table had a timestamp column tracking the last time it was modified....highly unlikely.

[Tribe Fan 24]

Looking forward to v7!

Kev

[Markus Heinsohn]

Some notes:
1) The database of V7 is so vastly different to V6, not a single OOTP 6 utility will work with it.
2) Will the game have a catobase-like feature? I don't know yet how I will code the history tracking in OOTP 7 so I can't comment on this ... but it could be possible, since the main problem (recycled player IDs) doesn't exist in OOTP 7 anymore.

[jarmenia]

Originally Posted by DaveHorn

There a a few different standards for a "SQL Dump" will Markus do a standard or his own thing? Who knows? If Markus uses a standard, little to no work will be required. If he makes his own thing, a data scrubber is a piece of cake. If I have to write a data scrubber, I'd rather go against straight text files than talk to a proprietary DB through an ODBC connection or any sort of ODBC bridge. I want all the data all the time. Third party tools such as BOSI and CATO use their own schema for a good reason. They are designed to do different things and have different needs. They need all the data all the time. I don't care what is new and what isn't new. Besides the only way to get updated data was if every single table had a timestamp column tracking the last time it was modified....highly unlikely.

If you want to run an analysis on closers over the last 10 years, you don't need all the data, just the data from the last 10 years on closers. All the extra "stuff" would just be thrown out. There's a reason rational databases are used, and this is a perfect example of when. The abiility to run a simple SQL statment and end up with a record set containing only data I want is standard prcatice. Remember, this isn't just for BOSI and CATO, its for all utility developers. This is assuming the database is normalized of course. If its not, the time it takes to run the SQL could be as long as it would to to the dump.

I just don't see the purpose of, essentially making a "copy" of the database which is exactly what you are doing if your going to dump all the data. Does that really make much sense?

[BigCity]

As a programmer, I would rather have the entire database. That way I don't have to worry if I thought of getting everything I needed - and having to constantly go back and redesign my input routines. Also, few utilities stay stable - revisions, fixes, and enhancements would constantly bring me back to what I was collecting - collect it all up front, then just deal with what you use.

I also want to emphasize to Markus to think out online league security. Yes, we want to output al the data - AND put it back in - but online league need to be secure

[Anachronism]

Agreed BigCity - I'd rather have the entire database myself that I can run calls against to grab what I need. I understand if Markus wants to make a dump of the DB to protect the game db as propietary knowledge, but still... being able to grab data from the core would be great.

Still... if Markus provides us with a regulation sql dump it is easy enough to import that into a new database.

Can't wait to be able to develop my OWN php site with the database

[DaveHorn]

Originally Posted by jarmenia

If you want to run an analysis on closers over the last 10 years, you don't need all the data, just the data from the last 10 years on closers.

I just don't see the purpose of, essentially making a "copy" of the database which is exactly what you are doing if your going to dump all the data. Does that really make much sense?

Unless there is a yet non-announced significant change AND OOTP begins to track historical data you are not going to have all the data on closers from the last 10 years in the database. That's part of the entire point. It will also be impossible for OOTP to track every piece of data we all want. So why bother? Just give us the data.

Other points I've already made were...

1. Database is likely proprietary. So should they write an ODBC driver for us? Hell, no, stick to the baseball engine. Just give us the data so we can use it.

2. Different tools that run on different platforms will be built to use the data in their own way. Is Markus going to write an ODBC driver for us in Linux or FreeBSD or the myriad of other hosting OS solutions? Do we want Markus spending his time on that or the game?

3. Said tools will be better and easier developed when they are using the data in their own schema. Fighting through a forced schema is a pain in the ass, that is why so many tools use their own schema.

I'm confident Markus is doing the 100% right thing by just giving us the data. So I won't bother arguing the point anymore.

[canadiancreed]

Can't wait to be able to develop my OWN php site with the database

you and me both

[DaveHorn]

Originally Posted by canadiancreed

you and me both

Hey guys, not sure if you are aware or not....but even if you don't use BOSI, you can use CommishJoe's exporter to do this already. Many sites already do.

[canadiancreed]

Originally Posted by DaveHorn

Hey guys, not sure if you are aware or not....but even if you don't use BOSI, you can use CommishJoe's exporter to do this already. Many sites already do.

Actually I wasnt aware of this. thanks for the heads up.

[LAH]

Great update. Now back to work....



Markus, Markus, über alles....

[TheRockCT]

Wow, although I wouldn't be able to write or program the first utility for OOTP7, it's good to see that v.7 seems to spark enough interest for others to surge ahead with Cato/Pierre/BOSI-like utilities, if they aren't able to be incorporated into the game itself.

[Comedian2004]

The key here is getting all of the data. If we could access the data directly, then Marcus would have a problem of one of our programs modifying 'his' data. Bugs would be terrible to trace down.

If the OOTP programs creates an ODBC entry on my machine I would be a happy puppy. Even if was a replicated version of the database.

If his program tracks HBP, but using SQL commands, I can't access how many times Radke hit Bagwell, then it defeats any purpose of it.

Marcus will have TONS of stats available, I am sure. But there is no way that he is going to have evey available one. And you have to remember, it should not really be saving calculated stats. For instance, batting average. Hits / At bats. Why save your batting average in the database? That is poor design of a database, since it is basically duplicating data. When you want to display data, you grab the at bats, grab the hits and do the math.

Marcus's main concern is to write the game, the displaying of the stats are toots and whistles, while a lot of the stats are standard, sure, but displaying what a team records is when Radke starts at home with less than 20,000 in attendance is our duty as 3rd party designers.

[jarmenia]

Originally Posted by BigCity

As a programmer, I would rather have the entire database.

No offense, but this statment alone makes me think you've never used ODBC. Please explain how selecting data via an ODBC driver is any different than selecting columns out of a spreadsheet? The difference to me is speed and robustness. If the layout changes, it doesn't matter. It does in a spreadsheet dump.

Originally Posted by BigCity

That way I don't have to worry if I thought of getting everything I needed - and having to constantly go back and redesign my input routines.

See my comment above.

Originally Posted by BigCity

Also, few utilities stay stable - revisions, fixes, and enhancements would constantly bring me back to what I was collecting - collect it all up front, then just deal with what you use.

This seems more like an argument for an ODBC connection. You run a SQL statment asking for certain tables / fields and you get the resulting recordset. The layout of the database can change and it has no affect on your program.

Originally Posted by BigCity

I also want to emphasize to Markus to think out online league security. Yes, we want to output al the data - AND put it back in - but online league need to be secure

While I don't agree with the rest of your post I do agree with this

[jarmenia]

Originally Posted by Anachronism

Agreed BigCity - I'd rather have the entire database myself that I can run calls against to grab what I need. I understand if Markus wants to make a dump of the DB to protect the game db as propietary knowledge, but still... being able to grab data from the core would be great.

Then you don't agree with BigCity. You're saying you'd like the ODBC connection as would I.

Originally Posted by Anachronism

Still... if Markus provides us with a regulation sql dump it is easy enough to import that into a new database.

Just an extra unnecessary step.

[jarmenia]

Originally Posted by DaveHorn

Unless there is a yet non-announced significant change AND OOTP begins to track historical data you are not going to have all the data on closers from the last 10 years in the database. That's part of the entire point. It will also be impossible for OOTP to track every piece of data we all want. So why bother? Just give us the data.

Ummm.. Version 7 is supposed to be a complete re-write, that's pretty significant.

Originally Posted by DaveHorn

Other points I've already made were...

1. Database is likely proprietary. So should they write an ODBC driver for us? Hell, no, stick to the baseball engine. Just give us the data so we can use it.

2. Different tools that run on different platforms will be built to use the data in their own way. Is Markus going to write an ODBC driver for us in Linux or FreeBSD or the myriad of other hosting OS solutions? Do we want Markus spending his time on that or the game?

3. Said tools will be better and easier developed when they are using the data in their own schema. Fighting through a forced schema is a pain in the ass, that is why so many tools use their own schema.

I'm confident Markus is doing the 100% right thing by just giving us the data. So I won't bother arguing the point anymore.

I didn't say don't do the dump, just give the ODBC access for those that know how to use it. In the case we're talking about here concerning OOTP the advantages are HUGE.

[jarmenia]

Originally Posted by Comedian2004

The key here is getting all of the data. If we could access the data directly, then Marcus would have a problem of one of our programs modifying 'his' data. Bugs would be terrible to trace down.

If the OOTP programs creates an ODBC entry on my machine I would be a happy puppy. Even if was a replicated version of the database.

If his program tracks HBP, but using SQL commands, I can't access how many times Radke hit Bagwell, then it defeats any purpose of it.

Marcus will have TONS of stats available, I am sure. But there is no way that he is going to have evey available one. And you have to remember, it should not really be saving calculated stats. For instance, batting average. Hits / At bats. Why save your batting average in the database? That is poor design of a database, since it is basically duplicating data. When you want to display data, you grab the at bats, grab the hits and do the math.

Marcus's main concern is to write the game, the displaying of the stats are toots and whistles, while a lot of the stats are standard, sure, but displaying what a team records is when Radke starts at home with less than 20,000 in attendance is our duty as 3rd party designers.

^^^^^^ GET'S IT

[DaveHorn]

Personally, I hope Markus worries about writing the game over such nonsense. I could care jack crap about having him write an ODBC driver for a proprietary database on an OS that I will not be using against a database schema that does me no good.

To Comedian2004 about your batting average example. Not sure of your point, but decisions are made all the time to use redundant data or store calculated fields because of performance reasons in real world applications.

[jarmenia]

Originally Posted by DaveHorn

Personally, I hope Markus worries about writing the game over such nonsense. I could care jack crap about having him write an ODBC driver for a proprietary database on an OS that I will not be using against a database schema that does me no good.

No one is asking for an ODBC driver on an OS that you won't be using. A windows ODBC driver, which most databases come with built it is nothing to include.

Originally Posted by DaveHorn

To Comedian2004 about your batting average example. Not sure of your point, but decisions are made all the time to use redundant data or store calculated fields because of performance reasons in real world applications.

You're correct here but the calculations Comedian was making would not fall into the catagory you are referring to.


One point I'd like to make, and maybe Markus doesn't realize this either. There is no reason for the database schema to be proprietary. Anybody with an ounce of knowledge could come up with a normalized rational database schema. Markus' intellictuall property is in his game engine, not his database format. I'm willing to bet once we have version 7 in our hands, it would not take long for somone to come up with a schema close to what Markus is using.

I know several companies that give out the database layouts to encourage their clients to read and manipulate their data. It serves the same purpose as what Markus' would, so he doesn't have to develope 10,000+ different reports. The engine that creates the data is what's worth money, not the wherehouse its stored in.