• (nodebb)

    The result was a bolted on monster of broken implementations of SQL that infuriated the few customers who tried it, Irving got promoted, and Taliesyn ran as far from the trainwreck as possible before the company flamed out.

    Taliesyn should have be been lacing up his best running shoes long before the end, about the time that he found out that Irving had meddled with the roadmap for his delusional SQL adapter, or maybe before.

    And yes, I'm aware that in a startup, you shouldn't ever unlace your running shoes.

  • TheCPUWizard (unregistered)

    Fast forward and discover LINQ [No, not the various extension methods that support method chaining and fluent syntax and happen to live in a namespace called LINQ, but the actual LINQ itself...

    var studentsGroupByStandard = from s in studentList
                                  where s.StandardID > 0
                                  group s by s.StandardID into sg
                                  orderby sg.Key 
                                        select new { sg.Key, sg };
    
  • Hanzito (unregistered) in reply to Steve_The_Cynic

    File_not_founder words have never been spoken.

  • Brian (unregistered)
    but we're using an object oriented data model which means we don't need to do joins or-

    Not sure I believe this. In every company I've worked that used NoSQL extensively (all two of them...), there was inevitably a need to join lists of objects. Except now we have to do it in the application domain, which means reading in all the data and mangling it in memory, dragging down the performance instead of letting the DB engine handle it.

    On the plus side, I've gotten really good with LINQ :)

  • Pabz (unregistered)

    Irving was an expert in AI? Yes, I suppose you could say his intelligence was very much artificial.

  • Duston (unregistered)

    I worked in a Lotus Notes shop (it was government, not a start-up), but they wanted to be able to analyze the data with Access (yeah, yeah, I know. You don't have to say anything.) For those unfamiliar, Lotus Notes doesn't have tables or rows, it has documents which may or may not have all the same fields. There was product that allowed SQL access via ODBC, but one query would take (and I'm not making this up) 45 minutes to run. I set up an automation to batch export the data to MySQL (still not ideal, but hey) and the time dropped to 5 minutes. Later on, we migrated to SQL Server and the time dropped to under 5 seconds. Fun with loosely organized data!

  • Hal (unregistered)

    It is hard to know what the issues really are here from the vague article. SQL support does seem like a feature that is going to be desirable in a database product even if it is a second class citizen because, frankly at least ANSI-SQL is a kind of least common denominator that is useful for integration. I don't understand why you can't map SQL onto an OO, or navigational database. Nobody reacts with incredulity at the concept of ORMs, this just going the opposite direction.

    Your Object classes become 'notional' tables, and child objects get some generated fkey, might even be something like the pointer to the offset in the physical storage, if you don't care about exposing some implementation details and don't require 'stability' accorss query batches. ie, if you query out person.spouse_id you can't run a separate query batch with WHERE spouse.id = ... and expect to get the correct the right person back.

    Again as I said it might have to be a second class citizen IE DML is supported but you can't do DDL from SQL etc, but I really don't understand what is impossible about mapping SQL statements on to object data or producing tabular outputs for object data. At the end of the day its a still a computer you have to be able to serialize the data so you should be able to locate it, reorder it, and serialize it out a different way.

    Honestly the WTF here seems to be nobody knows who was leading the project/product and so it simply defaulted to the guy bold enough to update the docs without getting paralyzed about not knowing who to ask. Seems more like a management problem than a software issue.

  • (nodebb)

    SQL itself isn't really the WTF... you can put together some very small version of SQL that doesn't support joins, perhaps, or is just suuuuuuper slow. That's pretty much what Conflient did by making a query language for Kafka, a technology that stores all data as individual log messages. https://www.confluent.io/blog/ksql-streaming-sql-for-apache-kafka/

  • (nodebb)

    IF (fat if) clients wanted to have a pseudo-SQL interface to query the data, and IF the company had the bandwidth to accommodate that request at the time (considering all other priorities etc.), they should have provided that feature to the clients.

    The article is a bit unclear on both of those "ifs" (or I didn't understand it perfectly). Sounds like Irving invented a requirement out of thin air, but then it says some clients tried it, so maybe there was interest?

  • (nodebb) in reply to Mr. TA

    Sounds like Irving invented a requirement out of thin air, but then it says some clients tried it, so maybe there was interest?

    It might easily have been people seeing it in the release notes or whatever, and thinking to themselves, "Hey, that sounds like it could be interesting, let's see what it does." Followed, apparently, by "I may barf".

  • (nodebb)

    *jibe . I'm not jiving you here.

  • ZZartin (unregistered)

    I mean a lot of NoSQL databases have ended up implementing SQL front ends because it turns out SQL syntax is pretty intuitive and powerful for querying data.

  • MrBerryK (unregistered)

    I’ve seen this anti pattern many times in my career:

    Marketing Dude: Het, MrBerryK, can our system do XYZ?
    Me: Well, maybe, if this improbable event happened and we spent 500 hours on implementing something that’s never been done before.

    A Few Months Later

    Manager: Hey, why is the XYZ feature late?
    Me: Huh? What?
    Manager: You said it was possible so Sales Dude already sold it to three customers!

    Moral of story, never say maybe. Features: Just Say No.

  • Duke of New York (unregistered)

    SQL is the sound the customer makes when the db crashes without writing

  • LZ79LRU (unregistered) in reply to Steve_The_Cynic

    So wait, this entire story can be summed up as:

    Boss: Add SQL. Worker: But I don't wanna! Boss: Do what I am paying you for. Worker: But I don't wanna!

    Boss goes to higher ups, gets the ball rolling and finally the worker is forced to do his job and make the feature the boss requested. Boss gets promoted, worker quits in frustration.

    The only WTF here is the worker.

  • ichbinkeinroboter (unregistered) in reply to MrBerryK

    I have observed the following, and it has helped me greatly in life, instead of just finding some people frustatingly flaky -

    a salesperson will pretty much only say "no" if they are sure they CAN'T a tech / engineer will pretty much only say "yes" if they are sure they CAN

    one has to have good idea to which type of person one is speaking . And even then look out for the "buts..."

  • Duke of New York (unregistered)

    If you overlook the significant parts about the boss not knowing or caring what SQL is beyond "a thing databases have", and lying about what a customer is doing in the field, and the company having more important improvements to work on, that's the story. In other words, if you have a reading comprehension deficit.

  • (nodebb)

    I don't see Irving as a boss of Taliesyn. They're peers. At best.

    A rogue dev or self-appointed "architecht" runs off and starts selling other workers, not customers, on the idea of a feature. Meanwhile there is no management at all paying attention as the product forks into two different directions each known to only a fraction of the people building it.

Leave a comment on “Structure is Structure”

Log In or post as a guest

Replying to comment #:

« Return to Article