Scott Aaronson disagrees with you, but OK.
Scott Aaronson disagrees with you, but OK.
If you want to understand the difference between Americans and Russians, compare GPS with GLONASS.
With GPS, each satellite transmits the ephemeris data for all satellites. That way, each receiver can track the satellites, so they know exactly where they are at any time, and also which part of the elliptical orbit they're in, so that they can correct for the fact that satellite is travelling faster at aphelion than perihelion, which affects the atomic clock speed due to relativistic effects.
With GLONASS, each satellite broadcasts X, Y, Z, X', Y', and Z'. That's pretty much it.
The difference between Americans and Russians is that Americans know how to build powerful consumer electronics which can do complex calculations, and Russians know how to inject a satellite into an almost perfectly circular orbit.
I expect Moore's Law, or similar, will eventually make it practical to fit a PC in your pocket, giving Android and IOS more competition.
But it's hard to predict when that point will be reached. It may also require PC applications that are not such power hogs.
Interesting. But they do seem like second-class citizens compared to "regular" columns in Maria-DB. It's extra syntax to use them. My approach would allow formality to be incrementally added without changing a column's "type" (mode?) from dynamic to static.
They also seem to require explicit type declarations. I prefer implied or WYSIWYG typing, a bit more like perl's typing model, even if it does complicate comparisons to some degree. (Different readers had diff opinions on how to handle dynamically-typed comparisons. I prefer a symbol next to the comparison operator, such as "#" for numeric: it's short and easy.)
Let me field that answer. They'll use it, just like organizations kept using WinXP pre-SP3, until the new Director of IT came along and said "Are you fucking kidding me?! What incompetent idiot let you stay unpatched and critically open to everything that has come along in the last fucking decade?! Oh, the same one who thought it's a great idea to never upgrade hardware, despite your staff barely surviving on machines that crash daily, or catch fire like those two did last week."
Oh, are PCs dead again? What is this, the 15th consecutive year they have ceased to be?
Sounds awfully like Prolog.
Not really. Prolog is mostly a query-like language; I'm not defining a language. SQL, or at least some variant of it, is good enough; no need for users to relearn the entire wheel.
(I've proposed an alternative to SQL, but it's probably not significantly better enough to dethrone the de-facto standard: SQL, for most uses. But that's a different topic.)
Oh dear gods, you want dynamic schema because planning is hard and relational database normalization is too complicated for you. Nobody sees the value in your asinine idea because you're an idiot.
Sometimes planning is hard. I've been in many situations where the customer doesn't quite know what they want yet, and/or some trial-and-error is needed to settle on an optimum design. Think of it as a prototyping tool.
Have you memorized every domain and customer preference in the world?
and there's no distinction between a missing column and one that didn't exist, how does hashing work?
Same way as before. I don't see that as a practical stumbling block, but maybe you have a specific use-case in mind that would muck things up?
Informal categorisation and structuring has its place, but that's an entirely different beast to a relational database.
Indeed with regard to informal structuring: something easy to get going is often useful for prototyping. One can then lock down this tool incrementally as things settle (or migrate to a static RDBMS).
I've been in rather long debates about the definition of "relational database", and found no clear-cut "failure" to match. Language is subject to interpretation.
Anyhow, the idea is to produce a useful tool. It's formal category or definition is secondary to being useful.
can't define relations in your dynamic database
Do you mean unique keys or "tables"? Please clarify. An example of what you are trying to achieve or match in a practical sense would help.
Maybe with enough training and experience, one may be able to pull it off, but a future maintenance programmer may not be able to follow your technique well. It increases the hiring and training burden for your organization.
There are techniques that work better under ideal conditions, but ideal conditions are hard to come by.
You know, some of us use windows since it's quite client facing. This might blow your mind. Anything either side can do to bridge the gap of best of both worlds is a good thing.
He made and sold a tool to commit crimes. Willingly and knowingly. I love how people so desperately want to ignore intent.
Okay, the Snowflake Meme has been overused. Move on.
Here's one description, but it's kind of meandering:
I'm working on a shorter description that I plan to put on github.
"If Diet Coke did not exist it would have been neccessary to invent it." -- Karl Lehenbauer