September 15, 2015 at 11:37 am
Answer me this, who is going to maintain your work when you are no longer around to do so? Are you training others to provide support? Do you expect others to pick up Garry's book and continue on?
Me personally, I'd walk away for any company using your database system. I have no desire to learn how to code and support the intricacies that are taken care of for me by SQL Server/Oracle/PostgreSQL/MySQL/Name your commercial RDBMS. I'll learn what I need to know about the internals to maximize performance, but I don't want to dive into and write the code.
People can use this TYPE of system for temporary use such as in: DATA MINING, DATA MIGRATION,
DATA EVALUATION, DATA NORMALIZATION, etc.
Even so, In this day and age, rarely do Permanent systems last longer than a couple years anyway.
As long as Business Rules are properly documented (as they should be), migration to a new system would not be any more difficult than what you would normally expect, and perhaps less difficult.
You wouldn't have to know how to program in Perl. Just know database design, and how to interpret business rules to code.
Heck, on my last job, I was hired to maintain/develop telecom monthly billing ETL processes which loaded EDI data to Oracle databases. They had their own proprietary scripting language which was not hard to learn. Later, they outsourced the rewrite of these dozens of scripts to overseas contractors to rewrite them in the Java language. These contractors didn't know what they were doing (business rule wise or EDI wise) and so I acted as QA providing constant feedback to them to tweek their scripts to properly interpret and populate the database tables/columns. It was not a problem of the previous code being written in a proprietary scripting language, but rather a failure of the overseas contractors to know the business rules of the company nor the EDI format interpretation relative to Telecom 811/4010. The company really didn't need to rewrite their ETL scripts, but how else is a CIO going to validate the existence of his/her position if he/she isn't always changing something (whether it needs it or not)?
This TYPE of system would also work well for Small/Medium size Businesses who do not wish to invest in a SQL SERVER DBA, nor IT staff full-time. A system like this could be written and implemented by a developer/contractor, then passed off to a semi-technical full-time staffer (say in Accounting or Marketing) for DB maintenance as long as documentation and perhaps an ADMIN menu was provided. A contractor could be consulted by phone,email,and texting if something came up for On-Call or Part-time assistance such as fixing a problem or adding a new feature.
September 15, 2015 at 11:51 am
erichansen1836 (9/15/2015)
Answer me this, who is going to maintain your work when you are no longer around to do so? Are you training others to provide support? Do you expect others to pick up Garry's book and continue on?
Me personally, I'd walk away for any company using your database system. I have no desire to learn how to code and support the intricacies that are taken care of for me by SQL Server/Oracle/PostgreSQL/MySQL/Name your commercial RDBMS. I'll learn what I need to know about the internals to maximize performance, but I don't want to dive into and write the code.
People can use this TYPE of system for temporary use such as in: DATA MINING, DATA MIGRATION, SYSTEM PERFORMANCE MONITORING activities, etc.
In this day and age, rarely do systems last longer than a couple years anyway.
As long as Business Rules are properly documented (as they should be), migration to a new system would not be any more difficult than what you would normally expect, and perhaps less difficult.
This TYPE of system would also work well for Small/Medium size Businesses who do not wish to invest in a SQL SERVER DBA, nor IT staff full-time. A system like this could be written and implemented by a developer/contractor, then passed off to a semi-technical full-time staffer (say in Accounting or Marketing) for DB maintenance as long as documentation and perhaps an ADMIN menu was provided. A contractor could be consulted by phone,email,and texting if something came up for On-Call or Part-time assistance such as fixing a problem or adding a new feature.
You still haven't answered the question. Are you practicing to be a politician?
A follow on questions. How many people do you know that do what you do? For the company or companies you have set this up, if you fell off the face of the earth, how many people are there that could walk in and support your application?
September 15, 2015 at 11:53 am
erichansen1836 (9/15/2015)
Answer me this, who is going to maintain your work when you are no longer around to do so? Are you training others to provide support? Do you expect others to pick up Garry's book and continue on?
Me personally, I'd walk away for any company using your database system. I have no desire to learn how to code and support the intricacies that are taken care of for me by SQL Server/Oracle/PostgreSQL/MySQL/Name your commercial RDBMS. I'll learn what I need to know about the internals to maximize performance, but I don't want to dive into and write the code.
People can use this TYPE of system for temporary use such as in: DATA MINING, DATA MIGRATION,
DATA EVALUATION, DATA NORMALIZATION, etc.
Even so, In this day and age, rarely do Permanent systems last longer than a couple years anyway.
As long as Business Rules are properly documented (as they should be), migration to a new system would not be any more difficult than what you would normally expect, and perhaps less difficult.
You wouldn't have to know how to program in Perl. Just know database design, and how to interpret business rules to code.
Heck, on my last job, I was hired to maintain/develop telecom monthly billing ETL processes which loaded EDI data to Oracle databases. They had their own proprietary scripting language which was not hard to learn. Later, they outsourced the rewrite of these dozens of scripts to overseas contractors to rewrite them in the Java language. These contractors didn't know what they were doing (business rule wise or EDI wise) and so I acted as QA providing constant feedback to them to tweek their scripts to properly interpret and populate the database tables/columns. It was not a problem of the previous code being written in a proprietary scripting language, but rather a failure of the overseas contractors to know the business rules of the company nor the EDI format interpretation relative to Telecom 811/4010. The company really didn't need to rewrite their ETL scripts, but how else is a CIO going to validate the existence of his/her position if he/she isn't always changing something (whether it needs it or not)?
This TYPE of system would also work well for Small/Medium size Businesses who do not wish to invest in a SQL SERVER DBA, nor IT staff full-time. A system like this could be written and implemented by a developer/contractor, then passed off to a semi-technical full-time staffer (say in Accounting or Marketing) for DB maintenance as long as documentation and perhaps an ADMIN menu was provided. A contractor could be consulted by phone,email,and texting if something came up for On-Call or Part-time assistance such as fixing a problem or adding a new feature.
And don't be so sure that applications only last a few years. I worked on an application in the 90's and 00's that should have been replaced in the late 80's and is still in use by that particular previous employer.
September 15, 2015 at 12:00 pm
erichansen1836 (9/15/2015)
... In this day and age, rarely do systems last longer than a couple years anyway.
I had an interesting experience about a year ago. I worked for an organization back in the '90s, I left there 15 years ago. I went there to have lunch with a friend, and as I was waiting for him to come up from the basement a guy walking by stopped and shouted "WAYNE! Remember that database that you wrote for us 20 years ago? We're still using it!"
You'd be surprised how long things can last. It may depend entirely on industry, almost all of my professional career has been in government in one form or another. In government, we tend to use things until either (A) they're replaced or (B) they're pried from the cold dead fingers of the last person using it who refuses to use the new system.
As long as Business Rules are properly documented (as they should be), migration to a new system would not be any more difficult than what you would normally expect, and perhaps less difficult.
Wow. Sorry. While broadly speaking I would like to agree with you, what you've been describing over the past several days doesn't sound like it would be easy to upgrade. I don't care how much documentation you've got on-hand to give to someone to upgrade your system, they would have to be an absolute expert in Perl and have very strong experience in SQL Server. While people like that are available, they aren't going to come cheap. I've done some programming in Perl, and I've been working with SQL Server and Access for 20 years, and I wouldn't touch your system to do an upgrade because my Perl skills aren't nearly good enough.
While upgrading from a Jet DB to SQL Server is certainly doable, what if The Powers That Be after you've left decide they're going to Oracle or any other database? SQL != SQL. No two versions are identical.
To be brutally honest, it sounds like you've done a heck of a job engineering job security for yourself at the expense of anyone else easily maintaining the system. I won't argue that it might be a fine solution for certain purposes, but of all the companies that I've worked for over the years can I think of a single project that I've been involved in or known about where it would be a good solution.
(it reminds me of an actuarial company that I worked for: all their code was in APL, which is truly Greek to anyone who hasn't worked extensively in that language)
Yes, SQL Server (excluding Express) is expensive. That's because it's a good and robust product, it is an industry standard, and there's tons of third-party books, training material, and consultants available to support it. That's why organizations pay money for it.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
September 15, 2015 at 12:09 pm
Even so, In this day and age, rarely do Permanent systems last longer than a couple years anyway.
Really? In the past five years, I have supported systems that are mission critical, in a variety of different industries, that are all at least 10 years old. Now more than ever, businesses are so focused on cost cutting and the bottom line that investment in new systems falls to the bottom of the budget.
This TYPE of system would also work well for Small/Medium size Businesses who do not wish to invest in a SQL SERVER DBA, nor IT staff full-time. A system like this could be written and implemented by a developer/contractor, then passed off to a semi-technical full-time staffer (say in Accounting or Marketing) for DB maintenance as long as documentation and perhaps an ADMIN menu was provided. A contractor could be consulted by phone,email,and texting if something came up for On-Call or Part-time assistance such as fixing a problem or adding a new feature.
There are far more resources available to small and medium businesses regarding mainstream systems, such as SQL, that completely negates any financial benefit of a system such as this. From Googling an answer about SQL Server, to spending very small amounts of money on a training class, a person at a small company will certainly be able to find help easier about SQL Server.
Please keep writing, selling and touting systems such as this!!!! Because I can retire much earlier on the money that I can charge when the call comes to make sense of this mess.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
September 15, 2015 at 2:44 pm
erichansen1836 (9/10/2015)
If you implement a Network database file system of 500 MDB files, each acting as a partial table within the 5 billion row database, each MDB file containing 10 million rows...
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 🙂
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
September 15, 2015 at 3:24 pm
J Livingston SQL (9/15/2015)
erichansen1836 (9/10/2015)
If you implement a Network database file system of 500 MDB files, each acting as a partial table within the 5 billion row database, each MDB file containing 10 million rows...
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 🙂
And what code is it that will determine the partitioning of those files and decide when a file is "full" and create another one and add that to the partitioning scheme, whatever that may be?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 16, 2015 at 8:11 am
erichansen1836 (9/9/2015)
The Jet I am referring to is the Jet Engine used by Microsoft Access 2002-2003. Jet 4.xYou don't need MS-ACCESS.
I refer to this database technology as
"REDUCTION DATABASE TECHNOLOGY" because you take MS-ACCESS software out of the picture.
Jet Engine databases can be 5 Billion Rows/1 Terabyte with instantaneous random access to any row.
As was said to the guys that discovered cold fusion; "Publish your findings".
If what you are doing is unique to a single system and can not be re-created with ease by any Software or IT professional then it is useless in a production business scenario.
If you have an easy to follow well documented process to create a new instance of this configuration and utilities with over 30 years of professional business use and development then this solutions is just as good as MS TSQL Server.
That is your free 5 minutes of why I would not use what you are mentioning and would port anything like that to SQL server.
This did not cover any reasons that deal with Hardware level process optimization, Replication, Emergency Data Recovery, En-Cryption (TDE style). Also did not ask for detail on how you Index and what caches Execution Plans so when you need over 10 TPS with more than one user connection to over 100 databases on the same 4 CPU server it works and does not spend two days accessing data.
September 16, 2015 at 8:18 am
erichansen1836 (9/9/2015)
I consider it downsizing to go to SQL Server from Jet Engine because my understanding is that SQL Server cannot match Jet Engine for size and speed. Can SQL Server provide instantaneous random access lookup to any one of 5 Billion database rows? Can SQL Server contain 5 Billion rows (MEMO field included) within 1 Terabyte of disk space?
Beginning to wonder if he knows.
These are both M$ projects or applications and share a LOT of the base code to do what they do.
Have you looked into File Maker? It also has brilliant stats like this. On one computer accessed by one person.
Like I mentioned in my other post. Publish a detailed listing of how to recreate this miracle environment.
Unless you are just trolling.
If that is the case you should go marry the Jet Engine, you won't find love for trolls here.
September 16, 2015 at 8:51 am
erichansen1836 (9/11/2015)
I think it is important to ask questions such as whether it is more prudent to use:MS-Access, MS-Jet Engine(w/o MS-Access), SQL Server Express, or SQL Server
for any particular database system design.
...... <way too much poorly written self serving information to quote/>
Without detail on how to reproduce your set-up that is easy to follow there is no way to answer your question.
I have read 6 pages of this thread and nothing here lets me know that you are actually looking for anything more than an argument.
Although I do wonder how your solution could be EASALY Used out of the Box to allow your database to be collocated on instances around the world with a Transaction in instance Peru being to instance Sweden?
Does it have built in Monitoring and optimization?
IMHO - You are asking why someone would want to upgrade from a stolen custom Formula One Race car to 20 red double decker Buses. There is only one option that makes logical sense depending on the if you need to move thousands of people or just one person to many places very fast.
Also some questions or details required to provide any answer with any professional quality.
Does this solution need to support Transaction Isolation?
Does it require ANSI certification and support of all ANSI SQL standards?
Do you need to deploy or work with RTOS devices?
Please PM me a response if you would like someone to actually help you with something.
I answer the questions you are asking for a living so this is what you get for free.
September 16, 2015 at 8:56 am
erichansen1836 (9/15/2015)
Before you upgrade from a file-based database engine to a server-based database engine, you must consider the advantages and the disadvantages of doing so. For more information about choosing the most appropriate database engine for your purposes, click the following article number to view the article in the Microsoft Knowledge Base:168549 Choosing the appropriate database white paper available in Download Center
Note Although this white paper is written for Access 97, this white paper also applies to Jet 4.0 and Access 2000.
Soooooooooooo
If you had this in your back pocket for the last 7 pages I am beginning to smell TROLL.
September 16, 2015 at 10:18 am
PHYData DBA (9/16/2015)
erichansen1836 (9/15/2015)
Before you upgrade from a file-based database engine to a server-based database engine, you must consider the advantages and the disadvantages of doing so. For more information about choosing the most appropriate database engine for your purposes, click the following article number to view the article in the Microsoft Knowledge Base:168549 Choosing the appropriate database white paper available in Download Center
Note Although this white paper is written for Access 97, this white paper also applies to Jet 4.0 and Access 2000.
Soooooooooooo
If you had this in your back pocket for the last 7 pages I am beginning to smell TROLL.
And 15 year old technology.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 16, 2015 at 12:50 pm
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 Smile
I think you missed the earlier postings where I gave example.
It is all about capacity planning upfront, data segregation, and file naming convention to pull this off.
I gave example of a 2010 U.S. Census database.
US_Census_2010_TX_A.MDB could be the name of the file containing rows for folks living in Texas whose lastname begins with "A". Same could be done for a range of account numbers, social security numbers, driver's license numbers, birthdate years, Sex and Ethnic Group, etc.
September 16, 2015 at 12:57 pm
erichansen1836 (9/16/2015)
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 Smile
I think you missed the earlier postings where I gave example.
It is all about capacity planning upfront, data segregation, and file naming convention to pull this off.
I gave example of a 2010 U.S. Census database.
US_Census_2010_TX_A.MDB could be the name of the file containing rows for folks living in Texas whose lastname begins with "A". Same could be done for a range of account numbers, social security numbers, driver's license numbers, birthdate years, Sex and Ethnic Group, etc.
I think you missed all the posts that could have answered the question you said you were asking.
You also missed any objective or informative response by your preachy posts that smell like tRoLoLoL bait.... :sick:
September 16, 2015 at 12:58 pm
Addicted -
Although I do wonder how your solution could be EASALY Used out of the Box to allow your database to be collocated on instances around the world with a Transaction in instance Peru being to instance Sweden? Does it have built in Monitoring and optimization?
You have no idea what you are talking about Addicted because you have not been actively following the Thread. You act as if this is a turn-key solution to roll off the retail store shelves.
I never presented this solution this way.
All I have shown is how it can be done, because it is a method not brought to the attention of the world before.
I have used MS-Jet Engine/ODBC enabled databases since Access 97 came out, both on Windows Peer-to-Peer and Windows Server Networks, but only until 2014 did it ever occur to me that a huge database could be maintained using *.MDB files as partial tables. And I discovered on my own that the tools needed to build this database already come factory installed on Windows 7 Home Premium (i.e. ODBC Admin Utility, MS-Access ODBC Driver), and JetComp.exe compact/repair utility is available for free download at Microsoft, and it is not hard to find a Free programming language with ODBC functionality (such as ActiveState Win32 Perl and Dave Roth's Win32::ODBC module and Aldo Calpini's Win32::GUI Native Windows GUI widget tool chest).
NOTE: If you don't like this idea, I have a second one to offer for Perl users.
Use Fixed-Length record TEXT files as I have demonstrated for *.MDB files, but use persistent Perl SDBM database files (tied to program hash tables) for immediate random access indexing to fixed-length record offsets(in bytes). These indexes can easily be rebuilt from the data in the Text Files and dont even need to be backed up . IMPORTANTLY, this is perhaps a true "NO SQL" system, and you don't need Data Access Components (DAC). When a Perl application user-interface to this database is compiled to EXE, it is a completely standalone system, and easily installed to client PCs. This is also a FREE/NO COST database access system for end-users (which you can develop for them), and to repeat, does not require Perl runtime or development components be installed on client PCs or the Server. And yes, this can be a relational database.
I call this Joint Database Technology, taking two relatively weak database systems, but using them together to create a relatively strong database system.
I call MS-Jet Engine/ODBC databases Reduction Database Technology, because the MS-Access software is eliminated from the equation, freeing Jet Engine to be all it can be.
Viewing 15 posts - 61 through 75 (of 245 total)
You must be logged in to reply to this topic. Login to reply