Drew Wutka
DWUTKA at Marlow.com
Fri Sep 7 00:09:31 CDT 2007
The beginning of the patent that you are talking about is discussing the problems of a system where you can't change the design of the tables while using the database. I built a system that got around that limitation. It's a 'data entry' system. We have several computers that record information from test equipment. An example would be our CMM machines. These machines measure things, optically. It's pretty slick, it uses a black and white camera that can tell you the height, width and depth of something, based on lines and grayscale equations. We make thermal electric coolers, so to inspect them, either someone is looking under a microscope and measuring things, or we can have the CMM inspect stuff, and report the measurements. With the first CMM, the guy working with it wanted to record the data into a database. He had two or three 'programs' that recorded their own distinct set of data. I wrote a custom database, with custom .dll's to record the data into the database. So his code (the CMM's have something called QBasic, which is a modified version of VBScript), would look like this: MyDll.CeramicWidth=SomeCodeToReferencetheCMMObjectModel MyDll.RecordData 'puts the set properties into a matching table in the database. About 2 years later, we bought another CMM. This time, however, they were planning on having lots of different 'programs', and were expecting more every time. With the original system, it's been in use for 4 or 5 years, and I've never had to add or modify to the original system I built for that one. But now I was faced with a system where the data they wanted to record could require new fields, with new data types, descriptions, etc, on a frequent database. The patent is discussing this situation, because it is talking about having to take a database 'down' to make these modifications. What I built was the CMM Data Acquisition program. The database had a few 'solid' tables, such as Batches, and Items. Items for the CMM would be the individual coolers that are inspected, and batches would be a group of items inspected at the same time. Then there was the Program table. It stores the details specific to each program. It's name, group, etc. Then the program field table. This table determined the field type, the description, the units, etc. Then there was a table for each data type. That table housed the value, the Item ID, and Field ID (The item table listed the program ID). So for every value that was entered, two indexed long integers were recorded for each value (be it text, currency, long, double, or date). There is a person that develops the QBasic code for each 'inspection' program. Instead of having to add or modify a table in the database, the database structure allows them to create a new 'program table' by creating definitions in the tables, and utilizing the multiple 'data' tables to store the same type of data, identified by item and field id's. So each program could be a different 'database design', when in reality, it's the same database just configured to handle an infinite variety of variable 'tables'. As an FYI, the goal was to use this database to record ALL test machine data, but I have never had time to go back and finish this system. It records the data without a glitch (in fact, to test it, I built in place an artificial data entry process, that just ran random number/data through batches. Let it run continuously overnight, and had the database at around 500 megs. Did some report tests, and the data reports I had ran at the same speed in the relatively empty database as it did in the system with several hundreds of thousands of batch runs (thus millions of items). I have basic batch reports, but the goal was to create a dynamic reporting engine, to let a user 'create' a report based on any 'field' (defined by the Program fields table), but just haven't gotten to it. This was not the first time I used such a structure either. Our company website (www.marlow.com) uses an almost identical process for the products. If you look the products on our web page, you'll see that the same page displays both cooler data, and data for other products like TTRSes, accessories, etc. This data is all stored in the same structure, not separate tables designed for the specific products. While a TEC (cooler) may have a Delta T attribute, a TTRS wouldn't. Our drafting department has 'control' of the product data, so they could add any type of product they want, from a TECs, to cars, to nuts and bolts, and the database never has to be redesigned to handle the different attributes of the item. Make sense? Not the exact same design of this patent, but the same idea. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Thursday, September 06, 2007 9:57 PM To: 'Access Developers discussion and problem solving' Cc: 'Jack Stone' Subject: Re: [AccessD] Database Patent This is an existing patent. The patent is date Feb. 21, 2007. Does your work predate the patent? Does it use this two-part scheme of the records data set and the categories data set? Or is yours a different technique which would duplicate one of the salient advantages of this patent which is the ability to alter the design of a database without interruption in the service? Part of what I'm trying to find out here, is knowing if this is a more or less common or existing technique or is truly unique. That would determine what value, if anything, the patent would have in a sale of the rights. How much of what you did can you share or want to share? Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, September 06, 2007 7:24 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Database Patent Is this an existing patent, or one that is applying for a patent? I ask, because I have actually built databases that pretty much use this principle. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin at Beach Access Software Sent: Thursday, September 06, 2007 6:48 PM To: 'Access Developers discussion and problem solving' Subject: [AccessD] Database Patent Dear List: A client who is a patent and trademark attorney is interested in opinions on a patent - basically it's a way to update databases on-the-fly by disconnecting the data from the data definition. You can download the patent by going to this web page: http://www.pat2pdf.org/ and entering the patent number 7003524. I guess I'm looking for opinions on whether this is a solution to a problem that exists and whether there is something of value in this approach. I know there's some deep database design talent on this list so I'm thinking this is the best place to start the research. Here's a teaser. From the patent: TECHNICAL FIELD The invention relates generally to databases and, more particularly, to the underlying schematic structure of databases. BACKGROUND Large databases running in publicly accessible environments are notorious for their inability to accommodate change. In today's world of massive access to large databases via the Internet, it is increasingly common to encounter messages to the effect of "database is down for maintenance" instead of the actual data requested. In a conventional database environment, when a change needs to be made to the schematic structure of a database, the data in the database must be extracted from the database in the old structure and re-written to the database in the new structure. If new data were to be inserted into the database while said changes were being effected, it could cause unpredictable effects to the database. Such effects could include corruption of pre-existing data, misapplication of database changes, misalignment of data relative to internal data boundaries, or any number of problems that could render the database effectively incoherent. Such results are untenable in most live database deployments. Conventionally, the most common solution to the problem of updating during changes to the schematic structure is to simply disallow it. Conventional databases also require a tight bind between the data type and the data storage. Users require that the data they request be presented in a manner consistent with the expected usage of the data. For example, a date may be stored in the database as a string of decimal digits (e.g., 20010303), but to present the data to the user in its raw form would be unacceptable. A conventional computer user requires that it be presented in a manner consistent with its usage (e.g., Saturday, 3, Mar. 2001. In order for the date to be presented in a manner consistent with its usage, the database must carry type-related information along with each unit of data. Binding between data and type is conventionally accomplished by organizing the data into metaphorical rows and columns. Rows of data are divided into pre-defined columns, where each column represents a particular data type and/or use of the data. Such data/type binding allows a computer program to make assumptions and inferences about the data appropriate to its type. Additional rows of data may be readily added to a database. However, if a new column is desired in a database, then the database must typically be made unavailable for a period of time so that data can be converted into the new format. Modifications to pre-existing programs would have to be made, along with the requisite testing and debugging necessary to validate any new code. It is also worth noting that in conventional databases there tends to be redundancy in the storage of data. For example, cities, states, zip codes, and telephone area codes may be repeated among a number of rows of data. Such redundancy results in inefficient use of memory. In light of the foregoing, it is apparent that there is a need for a system and method for modifying the schematic structure of a database without making the database unavailable for the entry of new data. Preferably, such a system and method would, among other things, also minimize redundancy of data in a database. SUMMARY The present invention, accordingly, provides a database in which an application program accesses data stored in a records data set (RDS) and a categories data set (CDS). The RDS contains at least one RDS entry having a data field configured for representing data. The CDS contains at least one CDS entry configured for being associated with at least one RDS entry and having at least one data type field sufficient to describe the type of data contained by the at least one associated RDS entry. The invention thus provides a database whereby data is isolated from its definition, thus avoiding the problems associated with the rows-and-columns model enumerated above, and permits the underlying schematic form of the database to be changed based on modifications to the CDS, without requiring any actual changes to the schematic structure of the RDS or the underlying database. By virtue of this same isolation it is also possible to reduce data redundancy with varying levels of granularity and create an object-oriented data model. MTIA Rocky -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.8/993 - Release Date: 9/6/2007 3:18 PM -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.