EEVblog Electronics Community Forum
Products => Computers => Vintage Computing => Topic started by: GlennSprigg on December 05, 2017, 02:40:14 pm
-
Again, pre-'Windows', I remember using 'dBase-III' and 'dBase-IV' within a company....
It was a Front-Line food production company, using automated production lines, in the late 1980's ?....
I was an Elect. Technician in charge of a crew, working with a 'mostly' free hand under various Engineers.
I promoted a 'computerized' maintenance system for various trades, as the 'repairs' were fairly non logistical.
Computers in such a work-space/place was limited then! and what was available then was nothing great!,
without spending big money, at the time..... (Boy, would that soon change!!!! :) )
We used some of the 1st IBM PC's available then, mono screen, NO hard-disk, 2 X 5+1/4" floppies, 64-kb RAM !
Booting into DOS, or (the then Ashton-Tate's) "dBase" that we chose to use.....
Obviously, to the uninitiated, this is a "database' application, that was designed to create/modify/search 'databases'.
Of course, this allowed the creation of the original '.DBF' data-base files that are still ref. today, as well as many others !!
ANYWAY.... 'dBase' was considered then as a computer language in it's own right!, and so apart from being able to
create/edit/manipulate DATABASES, one COULD, (and we all did!), via dexterously manipulating the 'code', to create
whole Applications, including Menu-Driven interfaces, data-analysis & reports, etc etc.
WE would also 'simulate' the 'Graphical' look of all the interfaces, within the 'DOS' style limitations.......
But we had all sorts of analytical results, including future data calcs. from charts & curves... to the following end..
The SYSTEM specified the specific maintenance required, and when, on every part of the production lines, from conveyor
Motor gearboxes to specific machine parts.... We even found that TOO much 'maintenance' was done in some areas, as
the cost of maintenance out-weighed the loss due to down-time in some areas, when there was a fault....
Some areas, had MANY other delays down the line, which would WARRANT the amount of maintenance performed.
I guess we pushed the 'limits' of 'dBase' at the time, but we did it !! :) (We had fun at the time, with our future ignorance).
LATER... I used a new custom written 'language', which I still play with today for REAL (old-school) process control.
Have a nice day...
-
I learned some dBase in highschool, somewhere in the previous millennium (we also learned Lotus 1-2-3). Can't say I remember any of it.
-
I do ;D
I used a tool called Clipper that compiled DBaseIII code into monolithic executables. Made a lot of tools for inventory, sales, monitoring repairs etc. Startup with the DOS floppy in A:, then change for the program floppy, data floppy in B:\
Those were the days.Cool, clean procedural programming. No object oriented, class based nonsense. When variables would and constants were.
-
I used dBaseII on CP/M on my TRS-80, built a database to store my record collection.
First job out of college, I designed a maintenance database using FoxBase+ for Mac, one of the first graphical front end databases - dBase code compatible but much faster. Later on I did many project with FoxPro DOS and FoxPro Windows. It later gained more object oriented features and Microsoft bought them out to apply their database technology to Access and SQL Server. FoxPro was INCREDIBLY fast, they had a technology that would dynamically spin up an index on a given search term if it determined the query could be completed faster if it first took the time to built an index - they called it Rushmore. It also supported SQL backends, Microsoft got what they wanted out of it and after a few versions left it to languish in favor of their standard Visual languages. A real shame, because data access was so much simpler, and since the language was data-centric, it was so easy to generate any sort of complex queries. Much better than doing it in something like VB.net where you have to convert everything to XML and back.
-
i remember Dbase, WordStar, CPM and lots of other stuff M$ ripped-off / infringed.
only to buy out the company's at the last second each time they got dragged into court over it!!
and lets not forget Netscape / Mosaic.
the list goes on and on.
-
I still use Visualfoxpro, who is a "superdbase + visual interface, that is a very powerfull tool still valid and quick in todays reality, even after microsoft kills the product.
-
And FoxPro.
Many accounting and service systems were built on dBase.
These were times, when you had to think about what next field cursor should move on tab and these were fast UIs. While you're moving mouse cursor around - half of form would be already filled in.
-
I still use Visualfoxpro, who is a "superdbase + visual interface, that is a very powerfull tool still valid and quick in todays reality, even after microsoft kills the product.
Hey....shhh....let them try to manipulate strings with .net :)
-
Our first IBM PCs had no hard drives. The first one we was made by Corvus (SP?). Fairly large external unit that I want to say was 5M. We used it to run D-BASE.
-
Sure, I wrote a bankruptcy management system in the programming language for dBase III. I forget the name of the programming language ("Clipper"?).
And before dBase (or the IBM PC for that matter) was available I wrote a specialized database in MS Basic on CP/M with a record size of 192 bytes (1.5x the 128 byte sector size of an 8 inch floppy disk). And I built the Ferguson Big-Board computer that it all ran on. This must have been the early 1980s IIRC.
-
Wordstar!
Lotus!
DBase!
Floppy Disks. The real thing, soft 5 1/4" floppies. With a mighty 360 Kb capacity.
-
Borland Paradox anyone?
-
All these names are sure bringing back memories
-
I had my last year at the university and used dBase III in combination with Clipper '87 and something that was called Clipper Tools or N-Tools (From Germany).
This was an amazing combination in those days.
-
:) :) Thanks to "ALL", for your comments & personal stories !! :) :)
It's amazing to think back on the things one could do, with enough effort, when we had nothing else !!
I think that limitation resulted in much more detailed/planned needs/results, and made our 'grey-cells' work... 8)
There's an interesting WebPage on it's history, here......
http://www.dbase.com/Knowledgebase/dbulletin/bu03_b.htm (http://www.dbase.com/Knowledgebase/dbulletin/bu03_b.htm)
-
Sure, I wrote a bankruptcy management system in the programming language for dBase III. I forget the name of the programming language ("Clipper"?).
And before dBase (or the IBM PC for that matter) was available I wrote a specialized database in MS Basic on CP/M with a record size of 192 bytes (1.5x the 128 byte sector size of an 8 inch floppy disk). And I built the Ferguson Big-Board computer that it all ran on. This must have been the early 1980s IIRC.
Yes, Clipper was more or less another dBase competitor, their claim to fame was it ran compiled and was WAY faster than native dBase.
If any from the US remember the S&L crisis in the early 90's - the way they (the Feds, operating as the Resolution Trust Corporation) took over a failed S&L, they would go in on a Friday at close, take the data (typcally mag tape in those days), process it over the weekend (because people would try to cheat the FDIC insurance limits by taking out additional accounts in 'creative' ways) and then on Monday at open have a full report of how much each depositer was owed and be ready to hand it out as they walked in.
The program that did all that matching and calculating was written in Foxpro for DOS and ran on what at the time were server class systems - Compaq Systempros - simply to get as much extended memory as possible, which Foxpro/DOS would use to cache data access. It was the speed of Foxpro that made this possible, not all of these failed S&Ls were little places with only a couple hundred accounts. I can't think of what it was called, that was over 30 years ago. I worked there for about a year as a consultant, towards the tail end of things, so I never got to participate in an actual closing, but I did do many a practice run with the app. The data team was pretty skilled - the app was decent, but it didn't do EVERYTHING - some knowledge of Foxpro/dBase was required to help things along, or massage the data between runs. And also convert any number of record formats from the mag tape to the common format used by the app.
I still relish my time spent on the various Foxpro projects I've been involved with, it was just so easy and quick to build data handling systems. Yes, doing string manipulation in VB.NET is an absolute PAIN. It dBase/Foxpro it's simple and easy.
-
not mentioned yet,
back then, everybody who had a computer knew how to use the keyboard! |O
M$ destroyed computing IMO, and created a world of icon-clickers who dont even know what a "carriage-return" is.
-
Apple was blaming Microsoft for copying the idea of mouse, icons, windows, etc. Ignoring the blatant fact that all the concepts came, fully-developed, from the Xerox Palo Alto Research Center (PARC). Typical corporate jingoism which is something that Apple perfected. Cue the Apple fanboys.
My employer uses a compulsory "nanny monitor" software on our PCs to monitor our computer use, keystrokes, and mouse movements. And to enforce "micro-breaks" every 10 minutes and full breaks every hour or so. Complete with suggested exercises for desk-jockeys to prevent RSI (repetitive strain injury). One of the suggestions is to learn the keyboard shortcuts to reduce use of the mouse.
-
I seem to recall that the origin of dBase was in a database program called "Vulcan"
Was it a Spock creation? :)
Be_Zero_Be
Poulsbo, WA
-
We still have a client who sends us DBF files once a week. This is using zmodem on a 14.4k dialup.
No idea what the hell they are sending this from. We dared not ask but they pay us a metric fuck ton of cash to keep this alive. Everyone else is using CSVs and SFTP.
We actually bought some Hayes modems off eBay incase the current one packs in.
-
dBase - yes plenty of dBase. And then when Norton Commander could read dBase format it was real fun. And then dBase with Image blob's and 256 colour VGA images.... Then you REALLY needed 20MB harddrive! (Or 28?MB with RLE cheat on Western Digital controllers)
SuperBase - for London Underground system.... (dBase "SQL" like with GUI frontend)
Clarion... GUI with relational database like dBase.
-
We still have a client who sends us DBF files once a week. This is using zmodem on a 14.4k dialup.
No idea what the hell they are sending this from. We dared not ask but they pay us a metric fuck ton of cash to keep this alive. Everyone else is using CSVs and SFTP.
We actually bought some Hayes modems off eBay incase the current one packs in.
not as dumb as it sounds, point2point is pretty secure unlike the net.
-
SCP+SSH over public internet is far more secure than unencrypted telephone lines. The latter can be intercepted trivially. The former cannot.
-
overlooking the spyware in the pc maybe.
but the sender may not be using a pc.
-
Sender is using a DOS machine we suspect.
-
Sender is an older organisation, probably still using a mini or even an old mainframe, and the data export using a PC running DOS is the most modern method, other than getting a weekly pile of line printed wide format paper to enter the data from.
-
Yep spot on. I sent an email to our account manager earlier and got a reply. It's an AS/400 and a rackmount supermicro PC running FreeDOS that dumps data out via scraping 5250 and farts it out over zmodem to us. They never got the source code for it from the contractor and it's a MS PDS 7 program from the dark ages. Apparently they are going to replace it when they get rid of the AS400, so never because they paid out for two loads of outsourcers to try and rewrite their software in Java and it never worked.
-
I wrote a savings account application in dBase II (CP/M) for a small financing and travel agency company after high school, it helped me buy my first PC XT Clone without monitor (I had to hack a black and white TV to bypass the RF tuner and input directly composite video). During college, I wrote and maintained another dBase II application (Patient record database) for a doctor, this time with MS-DOS and 20MB hard disk. For maintenance I visited the doctor's office once a month to backup the information to floppy (long long hours to backup 20MB to a bunch of 5.25" diskettes). On MS-DOS I used a TSR tool to design the screens of the application. With this tool, I had the screens designed and resided outside the dBase II programs. I don't remember the name of the tool...
dBase II gives me very good memories. I restored a Kaypro II just to load dBase II from a CP/M machine.
-
Yep spot on. I sent an email to our account manager earlier and got a reply. It's an AS/400 and a rackmount supermicro PC running FreeDOS that dumps data out via scraping 5250 and farts it out over zmodem to us. They never got the source code for it from the contractor and it's a MS PDS 7 program from the dark ages. Apparently they are going to replace it when they get rid of the AS400, so never because they paid out for two loads of outsourcers to try and rewrite their software in Java and it never worked.
how big are the transfers??
a pie or mid-end Nucleo board could grab serial and repackage it for transmission over the net.
only curious.
they are better off with simple hardware running freedos than some 8core overheating spyware infested shit that needs sevicing every 6 months to see if the psu caps are leaking!! >:D
i know a massive financial org that got a new it manager some years back, he binned all the ibm mini-computers running unix and spent 200,000 on quadcore dell machines w/support, and the same again on software licenses.
it took 2 years to get the junk actually running, and it still wont run aswell as the old stuff did. |O
why did he do it? because he was an M$ guy.
why does he STILL have his job? because he is from the small tribe we arent supposed to mention.
-
Apple was blaming Microsoft for copying the idea of mouse, icons, windows, etc. Ignoring the blatant fact that all the concepts came, fully-developed, from the Xerox Palo Alto Research Center (PARC). Typical corporate jingoism which is something that Apple perfected. Cue the Apple fanboys.
My employer uses a compulsory "nanny monitor" software on our PCs to monitor our computer use, keystrokes, and mouse movements. And to enforce "micro-breaks" every 10 minutes and full breaks every hour or so. Complete with suggested exercises for desk-jockeys to prevent RSI (repetitive strain injury). One of the suggestions is to learn the keyboard shortcuts to reduce use of the mouse.
Funny you should mention the nanny monitor software. At one of my jobs, where my primary task was working on the FoxPro application that more or less ran the entire place, we purchased another company and it was determined that the fastest way to integrate their data with ours was to hire a bunch of temp works to actually key it all in. One of the other programmers (there were 3 of us) and I wrote up a double-blind data entry form that also tracked keystroke rates and error rates. The first night of this data entry, they had about 20 people all set up and keying away. Standard 80/20 rule revealed itself rather quickly, 20% of the people did 80% of the work. Second night they retained only 10 of the people, with no reduction in total number of entries completed.
-
Yep spot on. I sent an email to our account manager earlier and got a reply. It's an AS/400 and a rackmount supermicro PC running FreeDOS that dumps data out via scraping 5250 and farts it out over zmodem to us. They never got the source code for it from the contractor and it's a MS PDS 7 program from the dark ages. Apparently they are going to replace it when they get rid of the AS400, so never because they paid out for two loads of outsourcers to try and rewrite their software in Java and it never worked.
how big are the transfers??
a pie or mid-end Nucleo board could grab serial and repackage it for transmission over the net.
only curious.
they are better off with simple hardware running freedos than some 8core overheating spyware infested shit that needs sevicing every 6 months to see if the psu caps are leaking!! >:D
i know a massive financial org that got a new it manager some years back, he binned all the ibm mini-computers running unix and spent 200,000 on quadcore dell machines w/support, and the same again on software licenses.
it took 2 years to get the junk actually running, and it still wont run aswell as the old stuff did. |O
why did he do it? because he was an M$ guy.
why does he STILL have his job? because he is from the small tribe we arent supposed to mention.
Transfers are about 200K. Hardly anything. It is plain text so that's a reasonable chunk of data.
I am just in the process of digging an MS partner out of the shite after they hit the performance wall and have just over 5.5 million lines of C# in one monolithic blob. They couldn't scale out due to shitty architecture and somewhat relied on the laws of physics being pushed hard to scale up. When you start spending £500k on SQL Server licenses you know you've fucked up somewhere. Slowly moving it all over to lots of little loosely coupled bits of software on Linux + postgresql + python + go + rabbitmq on AWS.
-
Microsoft pulled the rug from under the feet of many orgs by the way they remarketed and relicensed SQL Server Enterprise about three years ago. They’ve lost a lot of credibility from that, and they’ve had to recind a little by enabling some previously Enterprise features in the Standard edition. The damage has already been done though. SQL Server does scale, but you need expensive Enterprise fratures to achieve it. [My evidence is from rebuilding and re-engineering in execess of 300 SQL Server instances in the past couple of years, many downgrading from Enterprise to Standard].
Regarding still using dBase files, this sounds a bit like what Bernie Madoff got up to, keeping old systems for fear that upgrading them would reveal too much.
I remember Clipper and dBase very well. Microsoft buying out Foxpro was the next step in lineage and general business acceptance away from the big iron.
-
Yes this is one of those unfortunate companies who was screwed by the changes. I always warn people never to use any feature of their DBMS that aren’t portable as there’s no guarantee you’ll be able to afford them later or the product will scale with your business. This lot have CLR stored procedures, all sorts. Everything bad you could do they did it. Then again I’m being paid for them to ignore my advice so meh.
-
i know a massive financial org that got a new it manager some years back, he binned all the ibm mini-computers running unix and spent 200,000 on quadcore dell machines w/support, and the same again on software licenses.
So the "manager" has a brand new shiny paragraph on his resume for a "completed project", Dell got some $$$ out of the deal and so did M$. Good the the economy, some would call it a "win-win".
Yes that was sarcasm Sheldon.
it took 2 years to get the junk actually running, and it still wont run aswell as the old stuff did.
Yeah, but they are now running "new" stuff. New is always good. As for the users..they neither know or understand anything "IT" so "f^ck 'em".
why did he do it? because he was an M$ guy.
M$ can be very convincing, in most cases the guy or gal gets to keep his/her job. The project becomes such a tangled mess that even if you got rid of them, you'll have a hard time finding somene else to take it on, without another round of "overhauling ie throwing out everyting that stands in their way so they can complete the project using their version and understanding of "best practices" that are in effect that week.
because he is from the small tribe we arent supposed to mention
This one went over my head, I'm not up on on all PC puns :)
I don't follow #inclusion on twitter either :)
-
Yes this is one of those unfortunate companies who was screwed by the changes. I always warn people never to use any feature of their DBMS that aren’t portable as there’s no guarantee you’ll be able to afford them later or the product will scale with your business. This lot have CLR stored procedures, all sorts. Everything bad you could do they did it. Then again I’m being paid for them to ignore my advice so meh.
Problem is that database agnostic almost certainly will be a compromise, usually in terms of performance. While I agree CLR should be avoided, for some low level procedural stuff such as tightly iterative or non-standard string manipulation operations it’s pretty much the only way to make it perform inside a set based database operation.
The use of CLR is much more a problem of maintenance in my experience. You need a reasonably switched on person who understands the nuts and bolts of both the database engine and C#, and why it makes sense in some very limited use cases. There are frustratingly very very few procedural coders these days who understand enough or even think about set based operations on databases and how they're likely to perform, but project managers think all coders can think in a set based way, but in my experience usually they can’t particularly when it comes to understanding why something runs slowly.
The problem domain remains largely the same as it’s always been though, get your algorithms right up front, unit test them on a representative dataset, and everything else should reasonably easily fall into place. With so much abstraction nowadays, the performance thing tends to be addressed when it’s too late. Coders nowadays increasingly think of everything as a magic black box and then blame everything on “network” or “database” when their projects don’t perform, rather than their algorithms.
The main difference now is that today’s massively distributed systems add further dimensions of complexity, security and indeterminism that simply weren’t there 20 years ago. So, as well as good algorithms, you need good technical architects, or systems designers and integrators as we used to call them.
-
the biggest problem i have seen is company's needing data convertors/formatters to bridge between applications.
so instead of employing a 16year old coder to write some scripts, they go to some expensive outsourcing agency.
they go to a programmer and get the software written in Dot.Java-Pro 6.5 or something,
then supply it to the company without the sourcecode at very high cost.
5 years later - well you know how it goes!!
-
Yes this is one of those unfortunate companies who was screwed by the changes. I always warn people never to use any feature of their DBMS that aren’t portable as there’s no guarantee you’ll be able to afford them later or the product will scale with your business. This lot have CLR stored procedures, all sorts. Everything bad you could do they did it. Then again I’m being paid for them to ignore my advice so meh.
Problem is that database agnostic almost certainly will be a compromise, usually in terms of performance. While I agree CLR should be avoided, for some low level procedural stuff such as tightly iterative or non-standard string manipulation operations it’s pretty much the only way to make it perform inside a set based database operation.
The use of CLR is much more a problem of maintenance in my experience. You need a reasonably switched on person who understands the nuts and bolts of both the database engine and C#, and why it makes sense in some very limited use cases. There are frustratingly very very few procedural coders these days who understand enough or even think about set based operations on databases and how they're likely to perform, but project managers think all coders can think in a set based way, but in my experience usually they can’t particularly when it comes to understanding why something runs slowly.
The problem domain remains largely the same as it’s always been though, get your algorithms right up front, unit test them on a representative dataset, and everything else should reasonably easily fall into place. With so much abstraction nowadays, the performance thing tends to be addressed when it’s too late. Coders nowadays increasingly think of everything as a magic black box and then blame everything on “network” or “database” when their projects don’t perform, rather than their algorithms.
The main difference now is that today’s massively distributed systems add further dimensions of complexity, security and indeterminism that simply weren’t there 20 years ago. So, as well as good algorithms, you need good technical architects, or systems designers and integrators as we used to call them.
Agree entirely.
Especially about the lack of understanding. I throw people at Joe Celko's classic "SQL For Smarties" before they're allowed to touch our stuff. And then they get reviewed.
The cancer of any large MSFT stack though is the object-relational-mapper. This appears to turn into an adhoc 17-join table-scan filled cthulhu generator. Fusion IO made it shut up but that just made people assume that there was more juice to squeeze by ambling into a problem like a drunken zombie.
-
ORM is of little practical use in enterprise scale databases, it’s that same black box mentality where you’re so abstracted from what’s really going on, you’ve lost control, and when it performs well it’s by luck rather than design. They’ve tried to relieve the developer having to know or think about how databases work.
You can throw RAM and tiered storage at he problem, but that’s just a sticking plaster. Hardware vendors love it. As before it’s down to those pesky technical designs and clever algorithms that will save you.
17 table joins written by a human who knows what they’re doing can be reasonable, as long as it is written in a readable and maintainable way, but it’s at the extreme end of what can be able to be written in a readable way. When it’s machine generated, all bets are off.
A company I worked with hit a 256 table join limit with a human-written query. This was the result of a utopian manager who thought everything should be set based with no procedural stuff. Of course, a 256+ table join is impossible to maintain, it’s completely unreadable, and guess what it doesn’t perform.
Nowadays I regularly deal with 60+ table joins from code generators, the result of well meaning designers and managers who’ve taken code re-use to a whole new level. Just to parse and compile these queries takes tens of seconds. I have to concoct manually manicured plan guides for each build and use case as they bolt on more stuff each build: plan guides are even less maintainable than crap queries. That effort in itself rather negates the whole purpose of code re-use.
-
We still have a client who sends us DBF files once a week. This is using zmodem on a 14.4k dialup.
No idea what the hell they are sending this from. We dared not ask but they pay us a metric fuck ton of cash to keep this alive. Everyone else is using CSVs and SFTP.
We actually bought some Hayes modems off eBay incase the current one packs in.
Ha!! :) . I liked the "Metric F@#$ Ton of Cash" part.... :)
Not knowing what services your company offers, and the nature of the 'business' sending the data to you,
it would be hard to ascertain the reasoning behind their 'methodology' :)
Maybe they are just 'Old-School' and like it that way. Maybe they think it is 'safer' that way, avoiding more modern 'norms'.
Interestingly, where I am, in Australia, (not completed Nationally yet), we are now on the new "A.B.N.", (Australian
Broadband Network), which is all new 'Fibre-To-The-Node' as a minimum. There are NO 'Land-Lines' as such, when on
this new fully digital system, and the 'equivalent' to a 'Land-Line' is the new Routers using something like 'V.O.I.P' !!!
So the OLD 'Dial-Up' Modems would instantly fail miserably now :)
However, Aahhh.... don't you miss the 'Old' "Beep-beep-screech-beep-screech-screech" of the old analog 'Modems',
before they decide to 'handshake' with each other and then go mysteriously 'silent' as they continued to 'converse',
at a whopping 75 or 150 K-bits / sec... Sigh. And the 'Voyager Space Probe sent an 'LP' Record for our Alien friends !! :D
BUT... all this 'old' stuff still works in theory/practice, and was simple xxx, just lost now in the youthful hands of smartphones :)
-
Oh boy do I remember dBase :-)
First DB I ever used when I first started at college.
I hear all the MS arguments and such above now though, even if most of the work I do these days is M$ orientated.
That said, where possible, these days I try to persuade people to use PostgreSQL, which if anyone knows their DB history is actually the Farther of MS-SQL server, in a weird sort of Darth Vader/Star wars way.
Another fact quite a lot of folks don't relise these days however, is the Ashton Tate DBF (dBase) file format still lives on. Anyone who deals with a lot of GIS/Mapping data, will use DBF files every day, as the file format is used to hold column orientated "data attributes" in the ESRI Shape file format. If you download any SHP file archive from the internet, you'll find inside an SHP file, a DBF file and usually a PRJ and a few others.
The SHP holds the geographic points data, the DBF holds the attributes table, and the others are all just meta data with stuff like Projection system definitions and such like in.
It was without doubt though a hell of a database in it's time. Iv'e probably still got a copy in one of my many boxes of floppy disks up int he loft.
-
However, Aahhh.... don't you miss the 'Old' "Beep-beep-screech-beep-screech-screech" of the old analog 'Modems',
before they decide to 'handshake' with each other and then go mysteriously 'silent' as they continued to 'converse',
at a whopping 75 or 150 K-bits / sec... Sigh.
BUT... all this 'old' stuff still works in theory/practice, and was simple xxx, just lost now in the youthful hands of smartphones :)
Kill two birds with one stone and install the training sound as your ringtone. I did 8)
-
That said, where possible, these days I try to persuade people to use PostgreSQL, which if anyone knows their DB history is actually the Farther of MS-SQL server, in a weird sort of Darth Vader/Star wars way.
Not sure I understand the reference here, SQL Server was originally a Sybase product, and MS and Sybase shared source code and co-developed it.
An anecdote I have from an acquaintance of mine who was one of the MS SQL Server devs at the time MS and Sybase parted ways around the mid 1990s, regards part of the agreement to share the final codebase. MS responded by supplying Sybase with a fully functional and compiling build, but with all the white space and comments removed. I can’t remember if they mangled identifiers too, I wouldn’t be surprised, that is (or at least was) the kind of mentality that pervaded in Microsoft at that time. They even awarded trophies internally for pinching third party IP, badges of honour if you like.
-
Indeed. Postgres was derived from Ingres, a product which I have had the misfortune of using. SPARCstation 2, 16Mb RAM, SunOS 4, swapping 100% of the time!
-
dBaseII on a CP/M system... (8" floppies and all...)
Yup, I remember
-
That said, where possible, these days I try to persuade people to use PostgreSQL, which if anyone knows their DB history is actually the Farther of MS-SQL server, in a weird sort of Darth Vader/Star wars way.
Not sure I understand the reference here, SQL Server was originally a Sybase product, and MS and Sybase shared source code and co-developed it.
An anecdote I have from an acquaintance of mine who was one of the MS SQL Server devs at the time MS and Sybase parted ways around the mid 1990s, regards part of the agreement to share the final codebase. MS responded by supplying Sybase with a fully functional and compiling build, but with all the white space and comments removed. I can’t remember if they mangled identifiers too, I wouldn’t be surprised, that is (or at least was) the kind of mentality that pervaded in Microsoft at that time. They even awarded trophies internally for pinching third party IP, badges of honour if you like.
As bd139 pointed out, postgres derived from Ingres, and the code base for Sybase also came from Ingres, and since SQL Server came out of the Sybase code base, they both technically started off as Ingres.
However, the code that came from Ingres, that eventually became Postgres, didn't immediately become Postgres, it went through a few different itterations, some of which was forked back into Sybase, and ultimately made it into SQL Server.
So SQL Server is a product of Ingres=>Sybase=>SQL Server but also partly a product of Ingres=>PG97V1(Or what ever it was called)=>Sybase=>MS-SQL and also PG97V2 & V3 too, before all 3 products then went their ultimate final ways with Sybase becoming the base code for the ASX00 series of Database Servers, MS-SQL going off on it's own, and the early forked Ingress code bases, that fed back into Sybase, getting merged into what we now know as Postgres.
So Postgres is part brother and part farther to MS-SQL and for that matter Sybase too.
It hurts my head trying to think about it, I remember when I wrote my book on Postgres, that I had to speak to a number of members of the postgres team, to try and understand the DB's history, and it hurts their heads just as much as mine. :-) (Hence the Darth Vader reference)
-
Interesting history lesson that - thank you :)
-
Indeed, you live and learn. Just when you thought you knew everything about it: my SQL Server experience goes back to 1991, and apart for a couple of years here and there I’ve used it fairly intensively ever since.
I’m not sure how much Sybase is used these days, I haven’t touched it for about eight years or so. Never had the pleasure of Ingres or Postres, but have had to deal with Oracle in two intensive periods of my career, I never really gelled with Oracle, I found it very difficult when I’d spent so much time with one particular strain of database engine, you need to think very significantly differently in terms of physical configuration and deployment.
-
Very true. I’m a big fan of PostgreSQL. It just works out of the box with minimal tuning in most circumstances. SQL server is a close second. It’s amazing what you can throw at these.
One thing I am forever attempting to get our DBA team to do is start with default configuration and make changes only with measurable outcomes. We have a lot of voodoo cargo cutting going on. That is the only similarity between all database engines :)
I did a few years of oracle. Well to be precise, Oracle did a few years of me. Getting a working 8i install on HP/UX consumed about £50K of cash on consultancy and wall clock time. They run SQL Server now...
I’ve never seen a production sybase deployment. I have been assured that they do exist :)
-
All sounds a bit like my Career too :-)
I used a LOT of Sybase & Ingress in my early career as a national infrastructure engineer for Orange UK. Most of the back end databases (Well in the billing and financial side anyway) where all running on IBM & HP-UX systems.
In the Network OPS trenches where I was stationed however, we had all sorts of weird and wonderful stuff, such as the MML Interface for the Nokia DX200 GSM Systems that interfaced directly to the Subscriber Location Registry and IMEI databases.
Once I left GSM however and started going more into pure software development, I came across mostly Oracle stuff in big enterprises, MS-SQL in Ms based enterprises (No surprise there) and MySql pretty much everywhere else.
Oracle, well I'd rather do damage to myself with a rusty spoon, than use that pile of ((*^(&*^()*& , MS-SQL, it's bearable, esp if your using dotnet, and MySql.... please for the love of god will someone just kill it :-) kill it with fire....
Then I started doing a lot of GIS and Mapping work, and got introduced to Postgres, and that was it, it's my DB of choice where ever I can now, and for portable deployments, SQLite.
Both PG & SQLite can be configured to be simple features GIS specification Level 1, which essentially means if you have a GIS app that can run on Postgres+PostGis, then it should also run unmodified on SQlite+Spatialite.
And now with dotnetcore and the trully cross platform C# runtime, I also try to use Postgres on MS systems in preference to MS-SQL server, simply because I get the best of all worlds....
-
Thank you ALL again.... for your myriad of interesting & very varied comments !
The main 'upshot' being that originally, things were a lot simpler, and simply worked !
And using MINISCULE resources, on the most basic of systems. Of course, 'we' need to
'progress', and expand/diversify from the 'old', as depicted in many of these responses.
However, even today, we should keep the Adage going... "K.I.S.S." (Keep It Simple Stupid).
We seem to keep 'Reinventing-the-wheel', though in many languages :)
-
Thank you ALL again.... for your myriad of interesting & very varied comments !
The main 'upshot' being that originally, things were a lot simpler, and simply worked !
And using MINISCULE resources, on the most basic of systems. Of course, 'we' need to
'progress', and expand/diversify from the 'old', as depicted in many of these responses.
However, even today, we should keep the Adage going... "K.I.S.S." (Keep It Simple Stupid).
We seem to keep 'Reinventing-the-wheel', though in many languages :)
Back around 1990+/- a single individual could know everything they needed to know in the PC arena from cabling up a LAN and upgrading RAM to programming Clipper and Turbo C. They’d probably have some Novell Netware experience in there too.
Nowadays it’s simply impossible for an individual to know their way completely around a single database product such as SQL Server to the same level of depth and broadness we understood the need-to-know PC product space back then.
Regrettably this has led to pigeon holing of roles with limited exposure to technologies outside an individual’s area, particularly in larger companies.
So,e things have improved, though. The first production large sized database I worked on in 1992 was just under 1GB and it took an hoir to backup, and we pretty much had to have users off the system as it was so slow due to disk spindle contention. I can easily back up a 1TB database in that time now, with normal user online operations, thanks to tiered and multi spindle SAN storage.
I do ask myself whether the 1TB database gives a 1000 times better system than the 1GB one we rolled 25 years ago, and the answer is definitely not. The same online performance problems pervade for example, and there’s an extra middle tier or two in there. Developers are so abstracted now from what’s going on under the hood that fixing these problems is that much harder. The end users are definitely not 1000 times more productive.
While you could find developers who could code reasonable SQL and procedural stuff 25 years ago, it wasn’t common. It’s even less common now with expertise being pigeon holed and all the abstraction going on. You now need both a code developer and a development DBA, or more usually fix/hack that pesky database stuff after all the application code’s been designed written.
-
Thank you ALL again.... for your myriad of interesting & very varied comments !
The main 'upshot' being that originally, things were a lot simpler, and simply worked !
And using MINISCULE resources, on the most basic of systems. Of course, 'we' need to
'progress', and expand/diversify from the 'old', as depicted in many of these responses.
However, even today, we should keep the Adage going... "K.I.S.S." (Keep It Simple Stupid).
We seem to keep 'Reinventing-the-wheel', though in many languages :)
Arguably, that's one of the big draws of SQLite for me. It's a single file database, much like dBase was, and it's very low on resources, it's app driven (All you need is a DLL or linked library) there is no server, so you can compile it direct into your app, and it's ridiculously simple to use.
In my mind, SQLite is more or less, dBase in it's modern form I guess :-)
-
It’s also a rather nice bit of engineering as a whole.
I use the author’s (Richard Hipp) VCS as well (fossil)
-
The end users are definitely not 1000 times more productive.
No, but since "then", marketing and croud manipulation in general has become about 1000 times more effective.
As a result, systems can become specialized enough that you need specific "experts" for each one.
It churns the marketing machine, the certification machine, the job market and to some extent the educational system at the university level.
In turn the specialized experts convolute the specialized systems even more feeding the cycle.
So we have IT network experts that can't tell when the drive array has a problem and OS experts that can't tell when the network switch is acting up and the examples can probably go on forever.
"Computer" related fields are not the only ones suffering from this disease.
That's why now we have flebotomists , and automotive technicians with "Brakes" certification
It boils down to having enough specialization and enough of those specilazied "bodies" so there are more bodies to hire.
In real life you better know as much of everything as you can (if you are into that sort of thing).
When asked to draw seven perpendicular lines, post the meeting on youtube.
Come to think of it, somone needs to start sending recorded interviews to wikileaks :)