Fraudulent Mindset

These "attacking" titles ("fraudulent") need to go. It is not helpful. I suggest something like "IntegrityAndSafetyVersusNimblenessAndDynamism?". I'm leaning toward PurityVersusOrganic?.


This pattern discusses mindsets that programmers have which are fraudulent.. i.e. the idea that one mindset is obviously so much better than another mindset.
OOP Mindset

A quote from paulgraham.com (PaulGraham). Although it talks explicitly about OOP, the mindset itself is not limited to OOP.


Relational Mindset

Discuss why relational weenies have the wrong mindset here, etc etc

The entire idea of relational purism being perfect is fraud.. for example to think in "thin tables" just doesn't work. It's too hard, so it is a bad mindset. Unless, somehow, we can make it easier to visualize.. the idea that relational purism is the best way to go about doing data management in every app is just fraud.

Thin tables rule, they are the right mindset if our tools make them easier to create (so that we don't see them as overhead/separate hard things to grok and visualize. Think of them like different lists of data.. why have two arrays, or two linked lists in a program? What is so wrong with having more than one huge master wide array or linked list in a program? No one has fear of creating more arrays or lists in programs to manage data, but people seem to have FearOfAddingTables).

I often only use lists and maps in apps because they don't easily support local tables anymore, not because I like lists and maps. Stuff that's hard to grok and visualize creates is OWN problems.[DemandForEvidence] Trading visibility and simplicity for security/integrity-oriented bloat can be the wrong trade-off. It just trades one group of problems for others [DemandForEvidence]. WaterbedTheory. It can create conceptual mistakes that a clear system may have prevented [DemandForEvidence]. Conceptual mistakes are just as bad as security/integrity/type errors, and may even cause them [DemandForEvidence]. Trading KISS for safety may result in neither [DemandForEvidence]. Big companies often have armies of people who specialize in a particular portion of a convoluted setup ("complexity lawyers" of sorts) when a cleaner design would put them out of a job. Perhaps it is possible to throw bodies at the problem: If you have 500 rowers in your Roman-era ship, you never have to worry about the wind dying down (your integrity/safety). However, it is often not economical except in very critical apps (banking, medical, etc.). If the pre-motor ship absolutely must make a given trip on time regardless of the whether, then 500 rowers is indeed the right solution. However, it would bankrupt the economy if every ship did that instead of use sails.

I must admit to being curious as to exactly how thin tables are "hard to grok and visualize". Maybe for you they are. But big tables are like putting tons of facts together with one big conjuctive AND clause. (Santa is fat AND he's hungry AND he likes cookies AND he wears a big red suit AND he rides the sleigh AND he calls the reindeer AND he is generous AND he keeps a list AND carries presents AND he enslaves elves...). Further, it visualizes in one HUMONGOUS table that is difficult to properly view, much less visualize.

As a compromise, what if the DB provides a "wide" table view to the users and DBA as a default, while the column-centric sub-tables are more or less hidden most of the time and are just an implementation detail? And if its mostly a matter of safety, why not use constraints and triggers instead of skinny tables? Make the constraint/trigger language/protocol simpler for such maybe. --top

[The only place I'd prefer lists to tables is when doing certain forms of systems programming where I need to make guarantees on access times for message queues and such. That said, I believe skinny tables are often good things because, fundamentally, DatabaseIsRepresenterOfFacts and the use of hundreds of 'skinny' tables allows you to have each row represent exactly one fact. This also makes it much easier to add tables and update facts because (a) you never need to mess around with any 'central' table to add new facts, and (b) you don't need to specify the maintenance of the dozens of columns you aren't updating, and (c) there are far fewer problems with properly describing integrity constraints.]

It will be easier to use relvars (tables) as replacements for lists if they were simply made easier to use than what is currently offered with SQL and TCP/IP connection based databases. I find the main reason I don't use databases often enough is because they are very hard to access without a lot of upfront planning and work.. such as setting the server up, figuring out how to get the SQL sent over the connection, making the user accounts and passwords, etc. Sometimes we just need an embedded relvar similar to SQLite.. but we need some proper database and not a basterdized relational model such as SQLite with no types and no integrity. I suggest that this replacement for SQLite even be easier to use than SQLite, such as not requiring hard to do stuff such as constructing SQL strings.. rather something like RelProject. The relational model isn't successful so far because it has always been hard to use, and frankly no products out there are even truly relational.. except some infamous ones that are approaching true relational.. such as RelProject. I will continually harp on the fact that relational could be so much more widely used if we just offered some products that made it easy to use and easy to tap into. That is the main problem today.

[As far as 'simplicity' goes, a hundred skinny tables is far, FAR simpler to grok, view, secure (with per-table or per-fact policy), optimize, verify, AND manage (all at the same time) than is on big table with a hundred columns. Even top should know that a relational database already allows one to look at any 'view' one wishes, and any good RDBMS or TableBrowser can remember or suggest views, so visibility is an utterly fallacious excuse. I'm quite convinced that TopMind has never really grokked the nature of simplicity - not with the way he goes on and on declaring 'KISS' as an excuse to defend solutions that cause far greater complexity than do the alternatives. 'The Sun goes round the Earth' seems simpler than the Monty Python Galaxy Song, but it forces diligent observers (those who don't just wave away observations and blind themselves to all other evidence) to start AddingEpicycles to the motion of everything else. There is such a thing as essential complexity, or necessary complexity, and going simpler than that makes a notion 'simplistic' instead of 'simple'; simplistic solutions force everyone else to add epicycles. TopMind likes the simplistic. The EinsteinPrinciple reminds the wise: "As simple as possible but no simpler", but I doubt Top will wise up before he dies. So just take a warning: the moment Top starts waving his hands and throwing around the word 'KISS' (usually performed without justification, all the while dismissing other concerns and even insulting those who consider them relevant ("security/integrity-oriented bloat")), run. I should have; I think I become less intelligent and devolve into an angry ape whenever Top starts saying simplistic, simple-minded things in the name of 'keeping it simple'.]

[There are only a few (albeit significant) benefits to choosing one super-wide table. First, it makes queries a bit shorter - a simple select instead of a massive join. This is partially an accident of the query language; it would not be difficult to design query languages based more on DataLog that would be far better for working with 'skinny tables' (being designed for it). Second, the table will be nigh-guaranteed to possess exactly the same physical representation in the RDBMS as it possesses logical representation; this allows far easier complexity guarantees and reduces access costs. This is something that could be solved by allowing programmers to make explicit suggestions to the RDBMS optimizer. Finally, it's easy to remember; you don't need a smart browser because all you need is one word: a table name. The cost is, of course, the need to represent NULLs (which can be avoided entirely with skinny tables where each row-entry represents exactly one fact), the need to make 'special' changes (e.g. splitting off columns) the moment some columns can simultaneously carry multiple values, making any sort of automated physical-storage optimization far more difficult, making security of data (which is already hard) even more difficult because everyone needs access to the same table, making updates and inserts with the data-manipulation-language more difficult (because one must represent every column for both the input and output record), and even making maintenance more difficult (because changes to a big-arse table occur by nature of adding and removing columns, it forces one to (each time) touch nearly all existing DML statements; with skinny tables one only needs to touch the DMLs for just that table, but even the event would be rarer since there is never cause to split a column off a table. Oh, and there are also vast hidden conceptual costs: the inability to maintain meta-data for individual facts (e.g. temporal databases, security policy, source or indications of how the fact was derived, degree of confidence) is a big one; it isn't something someone can even readily think about before moving to skinny tables - an example (among many one can find in science) of simplistic notions making for stupid people who can't easily have other good ideas.]

In visual tools, why couldn't the foreign keys be visible as if it was a wide table? Example: it is duplicate in the visual view.. each table shows you a view of the entire wide table.. but in actuality, it is really a bunch of thin tables cleverly put together at the system level. Also, how to display normalization with the values plunked in a wide view, from the other normalized data in other tables? i.e. when you map "M" to "Monday" in another table, is Monday a peice of text, an enumeration, just a dumb label.. hmmm. Interesting to think about. In fact I'm going to load up MySQL query browser right now and see what it offers for different views with foreign keys - but I doubt it will have views for things like mapping a normalized table to a wide table - it may just have foreign key views, or maybe not even that.

[Answer: there is no reason that a TableBrowser couldn't take one look at the table meta-data and figure out how tables relate and allow views as though it were one wide table. Of course it would require a smarter browser than some we've seen. Good of you to not let TopMind's 'simple'-minded excuses interfere with your own thinking.]

Burgerkinging is one of the main advantages of relationial: "See it Your Way". Although existing RDBMS may not support such very well, the best compromise may be to make schema systems more flexible (table-driven) so that one can "query the schema" to present and find the view that they want, regardless of the physical layout underneath. --top

{OMG!!11!! I actually agree with this.} -- DaveVoorhis

When one is overly excited about TopMind finally showing some signs of agreement, we accidentally type out the number 1 on our keyboard instead of the exclamation mark. PwnAge.
Functional Mindset

What a bunch of hype and fraud:

Haskell is so much better because it doesn't have side effects, therefore more reliable than other programming languages.

Practical FunctionalProgramming is still in its infancy. There is a lot of research going on in mapping functional paradigms down to the relational database layer. A bigger advantage of functional languages are analyzable programs. You should be able to transform a succinct functional map or filter operation into an optimized DB query behind the scenes. The managed side-effects OnMonads help make the programs tractable to analysis.

Lisp is better because everything else is based on lisp.
Everything Is A File Mindset

It is a useful abstraction to consider some things files, but not everything should be viewed as a file. Some Unix gurus such as RobPike consider nearly everything a file - and this can limit their understanding of the relational model or other views. Not everything should be a file. See also the SawzallLanguage and the PDF file linked on that page.


Math Mindset

Math is fraud because ZeroIsWrong and one group of apples plus one group of apples can equal one group of apples, not two.

Physicists and scientists sometimes have quibbles and arguments with with mathematicians about issues in logic and in the world.

I recall once my physics teacher going into a great argument with my math teacher over what seemed such a minor detail regarding discrepancy between math and physics. Unfortunately I can't remember the exact topic they were arguing about - but the physics teacher came in and sat down in our math class and argued with the math teacher for about 1 hour straight (without a resolution at the end).

PageAnchor: Claims Bee

1. Stuff that's hard to grok and visualize creates is OWN problems. Don't you agree with this in general? I find it strange you would challenge this. I want you to confirm that you disagree with it. I often find the things you disagree with entirely strange, to the point I almost believe you malicious. For the sake of this argument, I am not accepting your claim at your word. After all, you've claimed elsewhere (AbsolutismHasGreaterBurdenOfProof) that psychology arguments and assumptions don't count.

I am not going to defend something that you do not explicitly disagree with. There's enough on our plates such that we shouldn't bother arguing for the sake of arguing. Thus, please commit one way or the other.

I honestly believe that seeing a proper defense from you for anything you claim is too much to expect. But feel free to waffle longer and prove it.

You are trying to reverse the burden here. It is fair and reasonable and text-saving to only defend something that you explicitly disagree with. I am not going to defend the existence of the chair just for the shear hell of it. If you feel otherwise, then this experiment is over and I consider you unreasonable. --top

Hah! No, Burden of Proof IS on you to defend your own statements, top, so there is no 'reversal' involved. It is fair and reasonable that anyone can, for any reason, ask that you defend statements that you make. 'Disagreement' is only among the reasons - skepticism, lack of comprehension, distrust, etc. are also potential reasons. Call me a distrustful skeptic if you need a reason to defend your statement. I can, after all, think of cases where I believe 'difficult to grok and visualize' is par for the course, but where it is overall 'simple' and solves problems - negative numbers would be one example, and monads would be another.

The fact that YOU think that I should prove something about my motives, or even offer or explain disagreement, makes it seem to me that YOU are the one attempting to shift Burden of Proof. It would fit what I believe to be your normal pattern: say whatever you want, make false promises that you'll justify it should anyone ask, when called to do so resist (as you are doing here) until you can get someone to explicitly disagree, when someone disagrees ask them to explain their disagreement, then force them to defend their disagreement and NEVER get around to actually justifying your own claim. Even better if someone offers a counter-example up front! then you can avoid most of the steps and jump straight to attacking. Are you planning to do this, consciously or unconsciously, in this case?

I stand behind my request as fair and reasonable and that it keeps wiki cleaner. Would other WikiZens like to comment on this stance? --top

Damn, if you aren't unreasonable. You even need second opinions before you become willing to justify your claims to a skeptic? I think you just seek excuse to dodge your burden of proof when you can't figure out how to shift it. Would other WikiZens like to comment on this stance?

Would you rather we stop at this stalemate? Fine by me. Admit it dude, it's utterly ridiculous to waste time justifying something that you don't even disagree with. It's dumb. Think about it.

I've already told you I don't agree with what you say, though it appears you require some remedial lessons in reading comprehension. And I think you've now proven yourself to be a ridiculously unreliable flake - you'd much rather waste time attempting to get a justification to justify things you should have justified in the first place, or waste time quibbling over slights against you or how 'rude' people might be, or demanding people "ask nice" before you provide a rational argument for an irrational claim, than you'd ever like to spend being productive. That's dumb. Think about it.

PageAnchor: "Top is Done" (hopefully in more ways than one)

Rational or not, normal human beings typically put up with only so much personal abuse before they shut out the perpetrator. In your very paragraph above you both accuse me of "waste[ing] time quibbling over slights against you" and ALSO call me an "unreliable flake". I am not going to put up with this any more. I find you too difficult a person to debate with. You have an odd sense of web etiquette that seems foreign to me and are anal about the wrong things. I'm done with this. I've grown a thick skin over the years taking on sacred cows, but not thick enough yet to deal with the likes of you. Maybe I'll cool down in a few months and revisit the issue. In the meantime, go harass somebody else with your excessive name-calling and zealotry. --top

2. Trading visibility and simplicity for security/integrity-oriented bloat can be the wrong trade-off. It just trades one group of problems for others.

First, is there ever any tradeoff between "visibility and simplicity" and security/integrity? Is security/integrity always free? Are you telling me that even you don't understand what you said? Wow, TopMind. And no, security/integrity aren't generally free (security, correctness, optimization, and reflection penetrate everything), but calling them 'bloat' will be rejected by most people, including me. So give evidence of where it is the wrong trade-off.

3. [Trading visibility and simplicity for security/integrity] can create conceptual mistakes that a clear system may have prevented,

4. Conceptual mistakes are just as bad as security/integrity/type errors, and may even cause them. Most rational developers will agree that conceptual errors can create security/integrity/type errors. I also find it odd that you challenge this. I want you to confirm that you disagree with it. I don't think you're in a position to make judgements about "most rational developers", as I don't think you're particularly rational. Can you define for me what a 'conceptual error' is? And can you prove to me that they are 'just as bad' as security/integrity/type errors? Depending on the definition, I might concede that one can cause the other, but I might deny that the whole 'can create conceptual mistakes' point.

5. Trading KISS for safety may result in neither [?] Is this about equivalent to saying, "And if I flip a coin a million times, it may land all heads!"?


AprilZeroEight

EditText of this page (last edited December 12, 2014) or FindPage with title or text search