• 4 Posts
  • 824 Comments
Joined 2 years ago
cake
Cake day: June 20th, 2023

help-circle




  • Java isn’t exactly hard, and it’s not particularly fundamental. It’s just bureaucratic, and Python will be both more enjoyable and more useful. Java was trendy in the 1990s and lingers on because so much Java code is still around. If your goal is to use a serious type system (Lisp and Python don’t have that), Haskell will be far more enlightening than Java. If you want to use the JVM for some reason, Clojure (a Lisp dialect that run in it) might interest you.

    For low level fundamentals, you want assembly language! That gives you almost no assistance and you have to do EVERYTHING yourself, organizing the program in your own head. For old fashioned imperative programming with lots of organizational assistance, try Ada.

    You will probably have to learn C at some point, but save it for later when it will be easier for you to spot the weaknesses.










  • What? Problems like this usually come down to some missing indexes. Can you view the query plan for your slow queries? See how long they are taking? IDK about SQL Server but usually there is a command called something like ANALYZE, that breaks down a query into the different parts of its execution plan, executes it, and measures how long each part takes. If you see something like “FULL TABLE SCAN” taking a long time, that can usually be fixed with an index.

    If this doesn’t make any sense to you, ask if there are any database gurus at your company, or book a few hours with a consultant. If you go the paid consultant route, say you want someone good at SQL Server query optimization.

    By the way I think some people in this thread are overestimating the complexity of this type of problem or are maybe unintentionally spreading FUD. I’m not a DB guru but I would say that by now I’m somewhat clueful, and I got that way mostly by reading the SQLlite docs including the implementation manuals over a few evenings. That’s probably a few hundred pages but not 2000 or anything like that.

    First question: how many separate tables does your DB have? If less than say 20, you are probably in simple territory.

    Also, look at your slowest queries. They likely say SELECT something FROM this JOIN that JOIN otherthing bla bla bla. How many different JOINs are in that query? If just one, you probably need an index; if two or three, it might take a bit of head scratching; and if 4 or more, something is possibly wrong with your schema or how the queries are written and you have to straighten that out.

    Basically from having seen this type of thing many times before, there is about a 50% chance that it can be solved with very little effort, by adding indexes based on studying the slow query executions.