|
Yes, it predates SQL - and back in the day, there was nothing like it. The original Pick database was actually a complete system. It ran native on hardware - no O/S. It came with it's own query language, procedural language and programming language. And, as a result, it was a very closed system. But I think one of the main reasons the Pick database didn't get the traction it deserved was Dick Pick's licencing 'antics'. It resulted in a whole bunch of Pick 'franchisees' - each with their own implementation and responsibility for maintenance and upgrades. All competing against each other - and against Pick Systems! If Pick Systems had had a savvy business strategy and half-decent marketing, there would probably be no such thing as SQL.
These days I work on Universe - a Pick derivative, which runs on Windows and Unix. It's nowhere near as closed off as those original systems, but definitely still has it's limitations. For instance: unlike most NoSQL databases, it doesn't cluster.
Sander Rossel wrote: I've found people are very defensive of SQL and very afraid of NoSQL (to the point of people becoming insulting and personal when someone, mostly me, mentions NoSQL). People don't like to get out of their comfort zones and they'll fight to stay there
Yep! That's why I got my insults in first - cheekily, calling them 'traditionalists'.  But, to be honest, I knew it was going to be a 'hard sell'. When I was first told about how the Pick database worked, (and there's a lot of other left-field stuff that I haven't mentioned), I was equally sceptical. I suspect no one is going to, properly, get NoSQL until they've worked with it - and actually done the job properly.
|
|
|
|
|
|
You will not outperform an RDMS since you will have to reproduce the lower-level code where all the performance is.
The query optimizer is not perfect; that is the only place where you can outperform; depending on the query and only if you appreciate granularity.
As far as textbox length goes, it's part of defensive programming. Someone will always try to insert 5,000 spaces and one character, just to see if they can.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
As far as NO SQL databases go, I think it is just another one of those cyclic “fads” like centralized vs distributed, rent vs own, agile vs waterfall, etc.
We used IBM Lotus Notes for every little one off app+DB that we needed.
Then we ditched Notes for email, so a lot of the more critical apps went to custom SharePoint workflows, now those are all being converted to Low Code/No Code apps on a cloud platform, in 10 years when the cloud platforms start leveraging their “hostage” power, everyone will shift back to on premise.
In 10 years, I suspect there will be some hybrid solutions where you have 2 refrigerator sized appliances that can support a 100,000 person enterprise. You just replace one of the refrigerators every few years to stay on maintenance.
|
|
|
|
|
I had my students develop the DB first; from that, one can easily build a web or desktop UI, independent from each other. Even other apps can access it, and when using a mainstream DB this decouples the data-layer from the rest.
5teveH wrote: First of all, we already do this. I'm pretty sure most developers would define the MaxLength for a TextBox and use a Calendar Widget for date input. Secondly, validation logic should be developed as reusable code - which minimises the need for future developers to learn and re-code that logic.
The max length, as a simple example, does apply as much to the DB as the UI. Most generate their UI based on the restrictions provided by reflection.
5teveH wrote: Performance. You are going to have to take my word for it, but I am 100% sure that with less disk, less CPU and less memory, I can deliver better performance than could be achieved using a traditional RDBMS. Also, indexing data does not have a performance hit. And the greater the volume of data, the more confident I would be that performance would be better.
You don't have to take mine; you gimme a model, I put it into 3BCNF and hand you the metrics. I do not ask for belief, I provide measurements.
Indexing data HAS a performance hit; the PC has to do something additional, how can you claim that the extra processing has no performance hit??
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Indexing data HAS a performance hit
True. I was responding to a comment about indexing variable length data having a much bigger performance hit - and that was not at all clear. Yes, I totally accept that everything you do on a system is going to take some resource - including indexing data. But, certainly on the database I work with, (which is completely variable length), there is no 'real world' impact when you index data. Which, I don't think is surprising. If you design a database from the ground up, to be variable length, you are going to deal with things like indexing variable length data as the rule, rather than the exception.
|
|
|
|
|
Variable length is a pointer to a blob. Indexing gives a performance gain if done right.
Enjoy. I'll be asking double to clean up after you.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You are going to have to take my word for it, but I am 100% sure that with less disk, less CPU and less memory, I can deliver better performance than could be achieved using a traditional RDBMS.
I'm not gonna. If you were such a wizard, someone would have hired you to write the next PostgreSQL and make a mint.
|
|
|
|
|
5teveH wrote: You are going to have to take my word for it, but I am 100% sure that with less disk, less CPU and less memory, I can deliver better performance than could be achieved using a traditional RDBMS. Also, indexing data does not have a performance hit. And the greater the volume of data, the more confident I would be that performance would be better.
And from a different thread...
5teveH wrote: after nearly 40 years of working with this database, (Pick/Universe),
I have been dealing with database for 40 years. Different databases. Different industries. Different types of enterprise systems.
And during that time I have also seen databases change. For instance just the infrastructure that they run on has changed enough that things that used to matter do not and things that were never even looked at before matter much more now. So that 40 years of experience doesn't even translate well into deciding what one should do now versus one did then. About the only real thing it allows is telling stories and being able better to recognize 'tribal knowledge' which is based on something that is no longer valid.
The first comment it completely open ended without restrictions and not even providing specific definitions.
In my experience making broad sweeping claims about anything always leads to one thing - failure. Followed by a lot of rationalizations and back sliding about what was really meant by the original claims.
For starters "performance" can mean almost anything but in the real world customers have real needs for what "performance" means. They don't care about benchmarks. They do care about how long they have to sit around waiting for results to show up on the screen and how long it takes to come up with new features that they think they need. (The two are not complementary.)
Moreover in terms of actual performance and the enterprise level performance is achieved by requirements modifications and not technology. One might gain a 1% boost with technology but might gain 6,000% by changing requirements. That last is based on a real world example.
|
|
|
|
|
Is USB just a pollinating insect that comes from America?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
USB kidding me
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Honey, I hope you queen see how silly this question is.
|
|
|
|
|
It's not often that one of these make me think, just usually chuckle, but this one did both. 
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn.
Stupid - An individual without knowledge and is incapable of learning.
Idiot - An individual without knowledge and allows social media to do the thinking for them.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
It's nice to wax nostalgic about these things, it gives me a swarm fuzzy feeling.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Depends on your definition of "B". Could be a female canine, from America of course.
|
|
|
|
|
OriginalGriff wrote: Is USB just a pollinating insect that comes from America?
That'd be weird since most of the bees in America are European bees.
|
|
|
|
|
This one is a nice compact flash of wisdom!!!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Have to skip since would be to rude.
Yeah, I'm almost home again
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
There - I said it! 
For almost 40 years, (apart from the odd dalliance with MySQL, SQL Server & Oracle), I have worked with databases that impose no such restrictions. So maybe I'm biased.
Here's my argument for removing the database schema 'straight-jacket':
- ASAP Data Validation. It puts the sole responsibility for data validation exactly where it should be: with the developer. The best place to catch bad data, is at the point of entry - before it gets anywhere near a database. That applies to user input and data feeds. If you are going to validate early, (and properly), there's no need to have a rigid database schema.
- Flexibility. It provides flexibility at no cost. A traditional RDBMS has a fixed data model, (defined by the schema), and will need effort every time it needs changing - and, these days, that responsibility is quite probably with another team: DBA's. If nothing else, this will cost time.
- Disk space. Defining a column size to accommodate the maximum possible length is a huge waste of space in a large table - particularly when there are probably dozens of those columns. For instance: a simple postal address table will need, at least, 5 x CHAR(50) address fields, plus a post/zip code field. And how many addresses actually use all of that space? Zero!
P.S. I'm now going out until the flames die down! 
|
|
|
|
|
OK, so you've stored your dates in your database as unlimited-length strings. With varying levels of "validation" on the front-end.
Now write a report based on a date range, given your table contains values such as "20190314", "1st May 2020", "32nd February 2990", "Third Sunday after Whitsun 21997", etc. 
And that's before you notice the significantly increased space it takes to store a string representation of a date over a proper date column.
Using proper data types in the database is precisely the kind of "straight-jacket" you want.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well I could validate at entry to ensure it's a consistent format - but, in practice, with the database I use, dates are stored as the number of days since 31/12/67. So, for dates since then, we are holding 1-5 digits - and for dates before that, there'll be a "-" in front.
If you tell the query language, (which includes an implementation of SQL), that the column is a date, it will figure out how to sort and select on that column. But that isn't enforcing any restrictions on how data is stored - it's just to help us use it when we need it - e.g. for a report.
|
|
|
|
|
If you're telling the data definition language a column is a date, why do you care how it's stored?
|
|
|
|
|
|
What you are bringing up is a foundational challenge of the Software Developer: where is the proper place for database-related logic. IE - How much does application do versus what the DBMS does?
ASAP Data Validation
You are codifying rules into your software that some else has to learn later on when/if a new application is built on top of the data.
If that is absolutely never going to happen (the data is only used by this one app) then you are correct, keep all the rules in the application.
But, what if later on the data in the database is going to be kept and a new App is being built, but now there are length constraints that you have to find all through the code? That could be very difficult when a dev down the road could just look at the length of the target field in the DB.
Flexibility
You said, "A traditional RDBMS has a fixed data model, (defined by the schema), and will need effort every time it needs changing"
But now this makes it sound like, "well, we'll create one big wide table with fields named Field1...Field200 and we'll just use it like a bucket. Make everything a huge varchar field."
But that can make the DB extremely slow also since fields will not be able to be indexed as easily.
Use Each Tool For It's Best Purpose
I like the balance of letting each tool do it's own work.
Here's what I mean by that:
1) allow the DB side handle lengths by implementing the built-in type system & field size constraints.
2) allow the software side (application) to do the programmatic types of things and much of data validation (insuring phone number is valid format).
3) Another good example is not using triggers. Triggers are like secrets that fire in the DB which later do some programmatic thing that can be very invisible to the developer. But this is programmatic type of code that should probably be in the app --- which helps you remember that the app is where data manipulation really occurs.
On your point, as a dev myself I can definitely see how you'd want as much _control_ of how the data is used in the application layer since we don't want to depend upon constraints that the DB Admin puts upon us. It just makes our lives more difficult & less flexible when we need to fix a thing that is happening in production.
There is no exact answer to this, of course, it is a ebb & flow type of thing & related to each shop and how they do it.
|
|
|
|
|
raddevus wrote: You said, "A traditional RDBMS has a fixed data model, (defined by the schema), and will need effort every time it needs changing"
But now this makes it sound like, "well, we'll create one big wide table with fields named Field1...Field200 and we'll just use it like a bucket. Make everything a huge varchar field."
That reminded me of a team project I worked on back in 2000 when one of the developers thought he had the best idea for a database for our new project. His solution was one table with ID, Title, and Value. That's it. Everything and I mean everything would be put into that table. "Easy Peasy" right? What a nightmare that was. 
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn.
Stupid - An individual without knowledge and is incapable of learning.
Idiot - An individual without knowledge and allows social media to do the thinking for them.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
