Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
What is the Best way to convert Uppercase values to camel case.
Lets say I have API with response {"name":"VIRAT KOHLI","teams":"RCB INDIA DELHI"}
Should it be handle at DB query level or Java level (Business logic) or at Client-side like using Angular pipes. What is the best practices and what is best in terms of performance ?
At database I am using simple JDBC query.
So I don't think there's a huge difference in performance or speed.
However, if you are working with a very large amount of data, doing the conversion at the database level could add a little bit more time.
It all depends on your context but you can :
Do it by Angular using the "TitleCasePipe"(https://angular.io/api/common/TitleCasePipe#titlecasepipe)
or
avoid repetition by doing a ".map()" on the received data by putting in camelCase the concerned fields (there are a lot of examples out there).
Do it on the Business layer of your Backend just making sure to do the transformation before sending the response.
Finally do it from the database (not recommended) but you have to take into account that the code is always faster than a database query.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need a very lightweight and persistent key/value-store in Java.
The amount of data is very very low and it should be very simple (getter and setter and all can operate on strings).
So I think of using some small NoSQL-DB or even giving some integrated collection a serializer/deserializer to the filesystem.
But I think NoSQL is a overkill and I hope a persister also exists for such a simple requirement.
Whats the best approach here? Any ideas?
You can either implement your own thing if it is a simple key-value string. (Have a look at Java's Properties class too in case it suits your requirements).
If your requirements are slightly more complex have a look at the embedded lightweight databases you can use. Maybe BerkleyDB might work for you. There are quite a number of others if you do a bit of search.
Also think about what you actually need to do with the data. Do you need to query it (so it needs to be indexed?) or do you just want to load it back all into memory? (in which case using a simple JSON or YAML text format would also suffice.)
Most Map<String,String> can be serialized. So for example look into https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html
there you find Serializable. Under that point information to help yourself solve the Problem.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm new to using a database, specifically MySQL. I'm creating a web application for class in which you can look up the name of a book and it'll display the summary of the book. My question is should I send a query to the database that collects all of the books' data on initialization and put them into a HashMap inside a manager class for lookup or should I use a query each time to lookup a specific book information?
It depends on the data transport time I would say. If your average query time times the number of request goes faster than a script to put everything into a HashMap, use queries. Otherwise, use a script that collects everything and puts it into a HashMap.
But if you have thousands of rows, you should use queries, because otherwise you will use too much RAM.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Please help me to understand how to expose service in REST.
Is it depends on RESOURCE or depends on the size of data ?
Example:
Let we take 2 resources (STUDENT & DEPARTMENT). Now I have an requirement of exposing "Total number of Students" and "Total number of Departments".
How should I expose a service now ?
Is it like exposing 2 different resource(api/student/total & api/department/total) ?
Or can it be do like this(api/total/student,department) since the response data will be very minimal ?
Should we consider the response size when deciding about Resources ?
It depends.
If you want a very clean interface, that sticks as strict as possible to the REST-rules, than use solution 1. I would recommend this if you expose your API to the internet for a broad audience.
If you want to optimize performance use solution 2. This would especially make sense if you know all the appications that use your API and sticking to official rules is less important.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a query which returns thousands of records (at some point it will). In that query I have some like this
Case when column in(:params1)
then :param2
when column in (:params3)
then :param4
when column in(:params5)
then :param6
when column in(:params7)
then :param8
END ABC
Now the question is what is better to do this in the query or return the column value and do the if\else in the pojo? And why? I tried testing it but currently don't have that much data.
Usually it is better (both because of performance and complexity) to let the database do as much work as possible for you. Doing the work in your application is likely to incur more network traffic than is necessary (which would decrease performance) and the code would have to contain all the nasty logic in it which would add complexity.
Also remember to avoid premature optimization. Try to avoid fixing problems that you don't have yet.
I would recommend letting the database do the work.
Returning thousands of records to the middle tier, operating on them, and shoving the result back into the database makes no sense to me. Why do all that network back and forth?
If you are truly processing that many records, I'd recommend considering letting the database do the work. No network traffic that way.
If not possible, you should make sure you truly need all those records. I'm betting you only think you do.
Writing queries this way seems like another bad idea to me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
At my work place, we use DAO pattern to hancle any sort of database operation. It hides bulky statements from programmer. Programmers need to write sql query and logic to handle output data. BaseDao handles all sort of operation and return output in required format.
I found that this class is not perfect. I added the code to control number of connections and to handle connection issues like slow connectivity, no connectivty, number of atttempts for connection etc.
But I would have to add more code to support advance feature of JDBC like providing/accessing binary data, Handling resultsets returned from SPs etc.
Is there any Java Framework or group of classes which can cover many of the database operations?
Please suggest.
I think that you are looking for Java Persistence API. It's a Java EE specification and Hibernate is the most popular implementation.
You could try Spring DAO instead. They have a nice template pattern for handling resultsets.
Or you can take another step step back away from JDBC and use Hibernate.
Spring Data JPA does even more abstraction than the other suggestions people have made. With that and Hibernate you don't even need to write queries unless it's a complex operation you need to perform.