September 17, 2015 at 8:58 am
Lynn Pettis (9/16/2015)
erichansen1836 (9/16/2015)
And 15 year old technology.
A Saturn V rocket is 40+ year old technology. Can it still be used to get to earth orbit and provide the astronauts with the vehicles to get to the moon and back? Yes.
In fact, because NASA has been screwing around trying to reinvent the wheel, we have not gone back to the moon. since the 70's. NASA wants to build a bigger rocket to take everything they need to the moon to setup a permanent moon presence.
There are a lot of strategies to go to the moon and back which they could have used the Saturn V rocket for.
We did not get to see these other strategies played out, other than Lunar Orbit Rendevous (LOR).
All I am doing is using Saturn V Technology (e.g. MS-Jet Engine), but using a new strategy never tried, nor communicated to consider.
Actually, from what I have read (several sources that I have no record of or can currently find), NASA does not have the technical knowledge to launch its last Saturn V rocket.
Of course, I may be wrong on this and what I read was a load of crap.
I actually can clarify this although I can not name the source.
NASA is not able to launch this rocket using current technology in a way that passes current Safety and Launch Protocols for less than it would cost to use different technology or some other rocket.
Since this was technology migrated from the ICBM project it makes sense that there are rockets designed purely for space travel that might be better suited for the job.
Kind of like the way that fits into the discussion.
September 17, 2015 at 9:02 am
Lynn Pettis (9/17/2015)
Riddle me this, why do you refuse to answer the questions I have asked you? Are you afraid of the answers that you may to give? Are you actually a politician disguised as an IT professional?You have failed to provide any straight forward answers to any of the questions I asked.
I too haven't had (or I have failed to notice, in which case sorry) an answer to this:
http://www.sqlservercentral.com/Forums/Topic1717865-3411-4.aspx#bm1719003
September 17, 2015 at 9:07 am
erichansen1836 (9/16/2015)
The nice thing about Joint Database Technology is that it is portable to any O/S platform.The user-interface could be portable too if you used Perl TK module instead of Perl Win32::GUI module.
And on UNIX systems, you are not limited to 4 GIG per each fixed-length TEXT file.
On UNIX systems you can have huge text files much larger than 4 GIG, although there is a limit on Perl SDBM files of 2 GIG using them as indexes to text file records.
For 4 GIG text files on Windows O/S, my SDBM database files never got larger than 1 GIG, so there is room for growth. Perhaps on UNIX you could take the text files to 8 GIG and the corresponding SDBM index file to 2 GIG.
I have not been limited to 4 GB text files since the late 90's.
The amount of terrible analogy, guessed solutions, and zero fact checked statements in your posts are starting to become very boring....
If you want to re-write the wheel then please do it. But may I sugest you not go to a message board run by people that make their living from the wheel and Post only arguments about how they Wheel wrong.
September 17, 2015 at 9:08 am
erichansen1836 (9/16/2015)
I remember punch cards, also paper tape. While in High School I loved taking the chads to the High School football games and using them like confetti. Others around us didn't like it, hard to get of their hair.
I used to take those little donut hole confetti and put them in envelopes and mail them to people so that when they opened them they had a mess on their clothes, desk, floor, etc.
And you shared this Sociopathic piece of Off Topic insanity because why? :sick:
September 17, 2015 at 9:22 am
and obviously the split mdb's add to the fun. It is a custom app after all.
Yes it is a custom app (any ODBC developer can do, whatever programming language), not a turn-key solution.
You save the cost of hiring a full-time SQL SERVER DBA, and you save by not having to purchase SQL SERVER and licenses. You are likely going to have Developer(s) on staff anyway writing end-user applications. The MS_Jet Database Admin is very easy to maintain, and can be kicked off from BATCH scripts kicked off by Cron Job like job scheduler on Windows Server/Windows Professional.
MDB files are not split really. The data is segregated logically between MDB files so that the DB application user-interface knows exactly which MDB file to go for sequential or random access.
Remember the US Census 2010 Database mentioned earlier as an example?
US_Census_2010_TX_A.MDB would contain the up to 10 Million (approx) rows for citizens who live in Texas and whose last name begins with "A".
The only exception is that you might grow such a database to include a couple instances of something like:
US_Census_2010_TX_A_1.MDB & US_Census_2010_TX_A_2.MDB
should the 10 million rows be exceeded.
Also, to make the huge database optimized, I had recommended using a separate MDB file for new ADDs(Inserts), and that Table's new records/rows merged into the overall database periodically just before running a system-wide JetComp.exe compact/repair operation which does all the: database, index, and query optimization. That MDB file would be the only other MDB file your application would need to inspect for rows relevant to your query.
This requires a little capacity planning initially, and logic written into the user-interface.
Most any database will fit this model, as the data should be able to be logically segregated in many or most cases. And I do believe that this would significantly increase both random access and sequential access.
September 17, 2015 at 9:29 am
Your original question or OP, whether you know it or not, is not new.
Neither is your sophomoric attitude and hateful Troll responses to honest questions that would have allowed for an intelligent discussion and not the Hate Debate you have created here.
You really asked why would I downgrade from a custom system that stores data using a custom coded file based storage system to a RDBMS. You may not know that is you question since you seem to barely understand what an RDBMS is and how it is different.
Not sure if you have worked on AIX ( you mention UNIX a LOT but not a flavor ).
Maybe when you read about Codd in the past you thought it was about Call of Duty downloads not the creator of the RDBMS concept.
I am going to just un-subscribe from this post understanding that if you actually read or understood anything about Relational Theory you would not need to troll your own forum post to feel good about being on the wrong side of an argument that was lost in the 70's.
If you do not understand what that means or are thinking "WHAT ARE DOES?" then you are at a place to make a choice.
A. Keep posting inane crap you think sounds intelligent
or
B. Start actually reading and learning something about the technology you are using.
Here is a good place to start with getting some facts.
https://en.wikipedia.org/wiki/Edgar_F._Codd
Pretty sure you are just going to ignore this helpful information and keep posting hateful Off topic troll bait like wanting to be Trumps VP.
If not there you go.. Another free piece of advise to the privileged hate machine trying to blow up my favorite forum for two days.
September 17, 2015 at 9:32 am
I have not been limited to 4 GB text files since the late 90's.
The amount of terrible analogy, guessed solutions, and zero fact checked statements in your posts are starting to become very boring....
If you want to re-write the wheel then please do it. But may I sugest you not go to a message board run by people that make their living from the wheel and Post only arguments about how they Wheel wrong.
Perhaps, but that may be because you have figured out a way to get around the INTEGER limitations of 2 GIG.
When you use READ/WRITE/SEEK/TELL type of file I/O operations on fixed-length record TEXT files, in order to SEEK to a particular record location, you have to give the location in bytes to the SEEK statement, which accepts an INTEGER value in the range to 2 GIG.
So what I have done is SEEKED 2 GIG from top of file, but also SEEKED 2 GIG from bottom of file to build my SDBM indexes. I store a positive integer byte offset value in the Key/Value pair of my SDBM indexes to SEEK TO from TOP OF FILE, but if the location of the record is past 2 GIG bytes, I store a NEGATIVE INTEGER byte offset from which to SEEK TO from END OF FILE.
September 17, 2015 at 9:33 am
MDB files are not split really. The data is segregated logically between MDB files so that the DB application user-interface knows exactly which MDB file to go for sequential or random access.
Remember the US Census 2010 Database mentioned earlier as an example?
US_Census_2010_TX_A.MDB would contain the up to 10 Million (approx) rows for citizens who live in Texas and whose last name begins with "A".
The only exception is that you might grow such a database to include a couple instances of something like:
US_Census_2010_TX_A_1.MDB & US_Census_2010_TX_A_2.MDB
should the 10 million rows be exceeded
can you explain how this works please "DB application user-interface knows exactly which MDB file to go for sequential or random access.".....would be good if you could provide example code please
as another question.....lets say I want to return all males in Texas...how does that work when we have separate tables based on "last name begins with "A""
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
September 17, 2015 at 9:37 am
erichansen1836 (9/17/2015)
I have not been limited to 4 GB text files since the late 90's.
The amount of terrible analogy, guessed solutions, and zero fact checked statements in your posts are starting to become very boring....
If you want to re-write the wheel then please do it. But may I sugest you not go to a message board run by people that make their living from the wheel and Post only arguments about how they Wheel wrong.
Perhaps, but that may be because you have figured out a way to get around the INTEGER limitations of 2 GIG.
When you use READ/WRITE/SEEK/TELL type of file I/O operations on fixed-length record TEXT files, in order to SEEK to a particular record location, you have to give the location in bytes to the SEEK statement, which accepts an INTEGER value in the range to 2 GIG.
So what I have done is SEEKED 2 GIG from top of file, but also SEEKED 2 GIG from bottom of file to build my SDBM indexes. I store a postive integer byte offset value in the Key/Value pair of my SDBM indexes to SEEK TO from TOP OF FILE, but if the location of the record is past 2 GIG bytes, I store a NEGATIVE INTEGER byte offset from which to SEEK TO from END OF FILE.
No I figured out how to stop using 386 memory architecture. <edited to add the eye roll>
September 17, 2015 at 9:48 am
can you explain how this works please "DB application user-interface knows exactly which MDB file to go for sequential or random access.".....would be good if you could provide example code please
as another question.....lets say I want to return all males in Texas...how does that work when we have separate tables based on "last name begins with "A""
It is actually one Table in the database, but segregated into many MDB files.
The Table is not split, but logically divided across many MDB files.
In most cases, a random access lookup is going to be initiated by the end-user supplying the State from a dropdown box selection (TN, TX, etc.), and the first letter of the LastName of the person they wish to pull up, plus other identifiable traits such as CITY/ZIP, RACE, GENDER, AGE RANGE, etc. A small result set would be retrieved and displayed within a srolling ListView for individual row selection.
The SQL statement would access a Table named the same througout the database file system e.g. CITIZENS.
You can have as many alternate indexes (with or without DUPS) on a table as you need, and 1 primary index (with NO DUPS). You can also open an unlimited number of ODBC connections to as many MDB files as you need, or open 1 connection at a time within a process LOOP, to retrieve the data you want sequentially or randomly from all the 26 TEXAS *.MDB files.
[In my capacity testing, I had 510 ODBC connections open concurrently to the same *.MDB file on my 2.2GHz, 3 GIG RAM, Single Intel Processor, Laptop with Windows 7 Home Premium O/S, and with the ability to produce reliable SQL query report output and SQL Updates on tables in that *.MDB file from each of the 510 open ODBC connections]
As far as returning all MALES in Texas, I would not allow the User-Interface to return such a huge result set from such insufficient query criteria specified. It would need to be narrowed down to return a much smaller result set for any client-side requests. Server-side requests like that could be done for data extracts(etc). No one needs that large a result set on the client-side because they could not possibly inspect so many rows within a ListView. What I might do is allow folks on the client-side to populate a bullet down TREE VIEW which had as the top level node CITY/ZIP, then when that node was clicked on, SQL lookup the database for all the males from that CITY/ZIP and display within a LIST VIEW widget. That is still a lot of rows to inspect. So I might make it SQL Lookup all MALES in TEXAS aged 50-65 (with other age ranges as separate child NODES) from a particular CITY/ZIP, to make the inspection process (and query result set) more manageble across a Network. This could be further narrowed down to TEXAS MALES of a specific RACE, CITY/ZIP, and AGE RANGE. These groupings are displayed to the end-user (client side) as CHILD NODES in the TreeView widget. Once clicked on, the narrow SQL statement is executed and the ListView populated for inspection. The user can then click on a ListView item to bring up a screen displaying just that Citizen's profile, perhaps with the ability to add notes to a MEMO column, etc.
NOBODY (in their right mind) wants their production database tied up during business hours by lengthy inefficient queries and batch update processes occuring either client-side or Server-side. A strictly ODBC controlled MS-Jet Engine DB user-interface can be designed to ensure access to the Network database from client-side is performed with efficient SQL syntax, performed only by authorized folks having specific user-access-level permissions, and limited to result sets of a manageble size.
As far as examples go, I am not logged in from my laptop with my code on it, so I will have to provide the code example tomorrow or later today for you.
September 17, 2015 at 10:46 am
PHYData DBA (9/17/2015)
erichansen1836 (9/17/2015)
I have not been limited to 4 GB text files since the late 90's.
The amount of terrible analogy, guessed solutions, and zero fact checked statements in your posts are starting to become very boring....
If you want to re-write the wheel then please do it. But may I sugest you not go to a message board run by people that make their living from the wheel and Post only arguments about how they Wheel wrong.
Perhaps, but that may be because you have figured out a way to get around the INTEGER limitations of 2 GIG.
When you use READ/WRITE/SEEK/TELL type of file I/O operations on fixed-length record TEXT files, in order to SEEK to a particular record location, you have to give the location in bytes to the SEEK statement, which accepts an INTEGER value in the range to 2 GIG.
So what I have done is SEEKED 2 GIG from top of file, but also SEEKED 2 GIG from bottom of file to build my SDBM indexes. I store a postive integer byte offset value in the Key/Value pair of my SDBM indexes to SEEK TO from TOP OF FILE, but if the location of the record is past 2 GIG bytes, I store a NEGATIVE INTEGER byte offset from which to SEEK TO from END OF FILE.
No I figured out how to stop using 386 memory architecture. <edited to add the eye roll>
So now we're saying 32 bit processors can't seek past 4 gigs? Tell me more!
edit: Seriously, I don't write big files, so I haven't had to deal with this, wheres the limitation?
September 17, 2015 at 10:59 am
Okay, Answer the following questions.
How do you handle backup/restore of the database, including full, differential, transaction log (or incremental)?
-- Definitions: Full, a full complete backup capable of being used to restore a database to a consistent state.
Differential, a backup of all database changes since the last full backup.
Transaction log or Incremental, a backup of changes since the last Incremental
How would you accomplish a Point In Time restore of the database due to a hardware failure?
What kind of RPO/RTO can you provide with your solution?
Who else can provide support for your custom application? Do you have any contact information with anyone should it be needed?
How difficult would it be to setup your application in a clustered environment? Mirrored environment? Replication?
I am sure I had other questions, but I have no desire to go back through all the posts to find them. If you refuse to answer these questions, then I suggest you just stop now as you obviously don't want a true discussion.
September 17, 2015 at 11:09 am
patrickmcginnis59 10839 (9/17/2015)
PHYData DBA (9/17/2015)
erichansen1836 (9/17/2015)
I have not been limited to 4 GB text files since the late 90's.
The amount of terrible analogy, guessed solutions, and zero fact checked statements in your posts are starting to become very boring....
If you want to re-write the wheel then please do it. But may I sugest you not go to a message board run by people that make their living from the wheel and Post only arguments about how they Wheel wrong.
Perhaps, but that may be because you have figured out a way to get around the INTEGER limitations of 2 GIG.
When you use READ/WRITE/SEEK/TELL type of file I/O operations on fixed-length record TEXT files, in order to SEEK to a particular record location, you have to give the location in bytes to the SEEK statement, which accepts an INTEGER value in the range to 2 GIG.
So what I have done is SEEKED 2 GIG from top of file, but also SEEKED 2 GIG from bottom of file to build my SDBM indexes. I store a postive integer byte offset value in the Key/Value pair of my SDBM indexes to SEEK TO from TOP OF FILE, but if the location of the record is past 2 GIG bytes, I store a NEGATIVE INTEGER byte offset from which to SEEK TO from END OF FILE.
No I figured out how to stop using 386 memory architecture. <edited to add the eye roll>
So now we're saying 32 bit processors can't seek past 4 gigs? Tell me more!
edit: Seriously, I don't write big files, so I haven't had to deal with this, wheres the limitation?
Was ready to flame on then I read your edit...
Seriously I do not know what he is talking about but the 4 gig file limitation was a limitation of the 386 architecture not being able to address more than 4 gig of memory.
Better detail on that is available here - https://en.wikipedia.org/wiki/Intel_80386
What made this even more fun to work with was a few years back HP sold a LOT of laptops with x64 processors running a 32 bit version of windows XP. This meant that the OS booted in a mode that did not allow it to use all the system resources as well as it could.
This mode was known as 386 mode... so that was where the snarky remark came from .
Here is some more information on that.
My point being was that this was not an OS issue like he suggested. It happened a lot on Mac using the x86 memory structures.
My other point is this post constantly reminds me of something a debate coach use to say.
"Make certain everything you say comes from a place that exists of Facts and knowledge.
Random incorrect stupidity is the mental equivalent of running into a gas can while you are on fire and waving your arms.
Nobody is going to help that person and he will never look smart or correct."
September 17, 2015 at 11:14 am
Lynn Pettis (9/17/2015)
Okay, Answer the following questions.How do you handle backup/restore of the database, including full, differential, transaction log (or incremental)?
-- Definitions: Full, a full complete backup capable of being used to restore a database to a consistent state.
Differential, a backup of all database changes since the last full backup.
Transaction log or Incremental, a backup of changes since the last Incremental
How would you accomplish a Point In Time restore of the database due to a hardware failure?
What kind of RPO/RTO can you provide with your solution?
Who else can provide support for your custom application? Do you have any contact information with anyone should it be needed?
How difficult would it be to setup your application in a clustered environment? Mirrored environment? Replication?
I am sure I had other questions, but I have no desire to go back through all the posts to find them. If you refuse to answer these questions, then I suggest you just stop now as you obviously don't want a true discussion.
I already know his answer Lyn...
"He has an app for that...." but it will cost you and it will have to run on all the users computers to work correctly.
Anyone remember FoxBASE Pro? I bet the OP would love it.
September 17, 2015 at 11:25 am
excuse me for being thick, but lets say for instance that I have a 50 million row table of sales transactions....do I assume that in your world of JET this would equate to possibly 5 separate MDB files?
if this assumption is correct, can you please explain how you query all 5 MDBs at once.....for example I need to retrieve all sales data for a specific customer....the actual transactions could be in any of the five MDBs?
I have no knowledge of PERL, so if this is a stupid question then please reply accordingly
Yes, it could be as few as 5 MDB files each containing up to 10 million rows for total 50Million rows,
but it could be segregated over more than 5 MDB files depending on how you logically segregate the data and the capacity planning you have built into the database user-interface.
Not really a PERL issue, since any programming language with ODBC support can be used.
Good question though.
Why not have several customer's data confined to a specific MDB file, and maintain an ADMIN table (in a separate MDB file) that maps customers to MDB files. An SQL statement would interrogate the ADMIN table to discover which MDB file to open for any particular customer. You could have 1 MDB file for each customer as an alternative. Or your could have multiple MDB files for one customer.
For example, Invoices in a specific range could be in one or more MDB files.
In an ADMIN table tracking customers invoices to MDB files, invoices in a specific range could be found in a certain MDB file, the name of that MDB file included as a column in the ADMIN table.
ADMIN TABLE
customer invoicefrom invoiceto MDBfilename
===================================
01 0000001 9999999 Cust_01_1.MDB
01 10000000 19999999 Cust_01_2.MDB
02 0000001 9999999 Cust_02_1.MDB
02 10000000 19999999 Cust_02_2.MDB
Also, you can have unlimited ODBC connections open to as many MDB files as needed, or 1 at a time in a process LOOP. With the proper Primary and Alternate Key Indexes on each MDB file, random access is not a problem even it it means gathering the data from multiple MDB files. It would not make sense to randomly insert NEW rows into this database system into just any MDB file, requiring uneducated lookups to ALL MDB files to determine where a paricular row or group of rows resided. Although this might not be a problem in a small database of 50 million rows and 5 MDB files, should the database be 15 Billion rows in 1500 MDB files, some performance deggrodation would be evident to the end-user if the user-interface was designed to search all 1500 MDB files to ascertain where a particular row was, even with random access lookup in each of these 1500 files.
CONSIDER THIS:
I've worked for companies with dozens of Oracle Database Servers, 1 for each client/customer.
If your ODBC data mining application wants to search for database data in a table common to all clients, that ODBC application has to connect to all Oracle Database Servers (1 for each client) to gather a consolidated summary report for the data in that common table, and across all clients/customers. This is an analogy to using multiple MDB files for a single consolidated database.
Most clients/customers prefer that you don't mix their data with that of your other clients/customers, and demand their own Database Server for their data, and their data alone.
Viewing 15 posts - 106 through 120 (of 245 total)
You must be logged in to reply to this topic. Login to reply