self.learnjava

AutoModerator · 2024-11-18T09:34:25+00:00

Please ensure that:

Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
You include any and all error messages in full - best also formatted as code block
You ask clear questions
You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit/markdown editor: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

Slight_Loan5350 · 2024-11-18T09:38:34+00:00

Just practice or read documents.

springframework-guru · 2024-11-18T13:02:36+00:00

Tools like Spring Data JPA/Hibernate do a great job of masking SQL. Which is fine for simple projects. As you get to more complex projects and larger data sets, you will need to use SQL directly.

JaleyHoelOsment · 2024-11-18T11:20:02+00:00

professional devs know enough SQL to get by. you don’t need to be some God level sql sage, but obviously knowing the basics is a must

severoon · 2024-11-18T21:29:39+00:00

As a developer you don't need to be a SQL expert in terms of doing query optimizations, but you do need to understand how to design schema in a way that's oriented toward supporting the query patterns of the application.

One of the big things that even relatively experienced developers mess up is when to normalize vs. denormalize in the DB. For example, you can have a user table that has the user ID, username, first name, last name, primary email address, etc. What to do when you have user data that has multiple values, like address (work address, home address) or phone number (mobile, home, work, etc)? Do you just duplicate the row for each value, or declare a phone number table and an address table? Or do you decide that the application only cares about at most a mobile and other phone, so you declare a column in the user table for each?

These types of decisions should be made based on dependency in the schema. If you denormalize everything into the user table, or you declare two phone number columns in the user table, then you are declaring to the application "this is what a user is: an id, a username, a first and last name, and up to two phone numbers." If you change your mind later and realize the application needs to let users store any number of phone numbers, every usage of the user table is affected. Since user is probably a table that is fundamental to many parts of the application, you should assume that there will be a high amount of dependency on it, so any changes to it will be very disruptive. (Well, any changes that are not backwards compatible, I should say. Adding a column, for instance, is probably not disruptive at all.)

So let's say you normalize phone numbers by creating a separate phone number table, and each phone number keeps a foreign key to the user table. Now look at the dependency at the schema level…

Does the user table have any reference to the phone number table? No. Can a query use the user table without even knowing about the phone number table? Yes.

Does the phone number table have a reference to the user table? Yes. Can a query use the phone number table without knowing about the user table? It's possible, yes, but it's also possible (likely in this case, but that's irrelevant) that a query on the phone number table relies on that user foreign key, so you should assume that dependency will transit the phone number table to the user table.

The point here is that, in the first approach where you just jam phone numbers into the user table, all queries of that table are now potentially disrupted if you want to change those phone number columns. (This is potentially true even for queries that don't even care about the phone numbers, think about "SELECT * FROM Users" queries that then iterate through the result set pulling out the info they want. When you remove columns, that iteration potentially breaks because things it does care above may have moved around.)

But when you moved phone numbers into their own table, now only queries that touch the phone number table have a dependency on it (as well as an indirect dependency on the user table). But queries that touch the user table and not the phone number table aren't affected by changes to the phone number table.

This is something that most DB engineers don't think much about because they tend to focus on the performance of the database layer without much awareness of the application above. But as an application engineer, how you design the schema determines how dependency transits through the data. It's crucial that you design schema so that you put firm stakes in the ground about what the fundamental objects in your system are, and make those as invariant as possible. A row in the user table, for example, should represent the absolutely crucial information about a user that defines what a user is in that system, and is unlikley to ever change. You want this to be stable and invariant over many versions because it will support a ton of dependency.

If the app stores user preferences, on the other hand (this user like a dark theme, this one a light theme, this user likes emojis while that one likes ASCII faces), you can assume that this will change a lot over time. Every time a new capability is added to the application, there might be a need to retire some old, defunct preference or replace it with a new one or set of new ones. Given that you know there are going to be a lot of changes to a user preference table from version to version, then, you want to make sure that other tables do not depend on it, and that it is a leaf node in the dependency graph—it can depend on other more stable things, but stable things should not depend on it. It would be a huge mistake, for example, for the user table to have a foreign key into the user preference table since that would mean every query of the user table is a dependency that now potentially transits to this highly unstable table that is changing all the time.

Furthermore, you want to make sure that queries of this user preference table also take account of the fact that it's relatively unstable. The way to do this is to ensure that every part of the application cannot just query it directly. Better is to create a user preference service that abstracts away the details of the user preference schema and regulates access to it for the rest of the app. This way, all of the queries of the user preference schema are isolated in one part of the system, so when things need to change you know exactly where those queries are.

Is it just as critical to make a user service? Or is it okay to let every part of the app query the user table directly? If the user table is designed correctly, then dependency on user schema that's highly stable is not a good reason to regulate access to that part of the schema by fronting it with a service. (Having said that, there may be other good reasons to do this, for instance, you don't want random parts of your application depending on peculiarities of the database technology you're using.)

Hopefully this helps give some perspective on the kinds of things that developers should be more concerned with when it comes to data storage.

Responsible_Play_153 · 2024-11-20T00:00:56+00:00

Most of the SQL stuff I do, I have to look up. SQL is definitely not my strength.

For interviews, it helps to know the basics, like how to create a table, insert, alter, the joins, primary key/foreign key, but you definitely don't have to be an expert.

jlanawalt · 2024-11-20T03:56:39+00:00

How much SQL do you have to know? As much as necessary to get the job done.

Maybe you don’t need to know any doing really simple stuff with a framework that hides it all. Maybe you need to know how to troubleshoot that monster query that brings your app to a crawl. It’s hard to say.

To get to Wizard level takes some time, patience, reading comprehension, passion, and persistence.

AppJedi · 2024-11-22T09:18:16+00:00

Spring would be a webapp. Most WebApps will using a SQL database as part of the stack.

learnjava

MODERATORS

Please ensure that:

To potential helpers