Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
What is a CRUD table and what is it used for? Is this just another name for a hash table?
I know that CRUD stands for create, retrieve, update, and delete. Are these not just the functions of a regular DB table?
Could someone give an example, maybe in Java?
There is no CRUD table. CRUD refers to operations on a table: create, retrieve, update, and delete. Those operations can be executed on any table. They are bundled together as they are the most basic operations.
A large number of applications that people write are 'crud'. They are simply creating entries in a database, reading them, updating them, and deleting them. Managing users, bug tracking, retail stock inventories... all mostly CRUD with various business logic wrapped around it from time to time.
There isn't such a thing as a crud table. Its just the most common type of application you will find out there, and a good bet what most programmers find themselves writing time and time again.
That the name crud is synonymous with 'dirt, filth, or waste, or something of poor quality' shows part of the distain that many people have for writing such applications. On this theme, some people will jokingly refer to "Create, Retrieve, Alter, Purge" as another form of the application.
Related
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 have to build a search functionality where GUI will provide a search field to search objects in Oracle database. There are currently 30K objects I have to search on but they will grow in number over time. 300-400 per month approx.
As a part of the requirement, when user types in any text in search Like for example "ABC", then all objects in the DB that contains ABC should appear in a datatable more like system is predicting results based on what user has types in the search field.
Question is how to architect such feature?
Simple way to do is to load everything in the GUI Javascript object and run search on it. Since JS is ridiculously fast, performance wont be an issue.
Another way is to run query in the Database everytime user types in text in search field. This does not seem convenient as it will put unnecessary load on the database.
Is there a better way to architect this feature? Please share thoughts.
premature optimization is seldom useful.
300-400 object growth per month with a 30k base object is nothing at all for any DB to handle.
loading all 30k object at once on the browser is awful and may affect performance while querying result in the DB will not have this problem until you have LOT of and LOT of users accessing the DB.
You should be building the service using the Database and then if/when you reach a bottleneck you can think about optimization trick such as caching frequent queries on the database.
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 5 years ago.
Improve this question
While working on a Java web application I was wondering if my model layer was written as it should be. For instance, let's say we have a table USER in our SQL database which consists of 15 columns. Now, when we SELECT all of the columns with SQL we map it to a Java class, serialize via JSON and send it via network to some View and show it on screen.
In a second scenario, we want to select only 2 columns on screen so we do SELECT c1,c2 FROM USER. Thats where my question comes in... am I supposed to map those columns to a same Java model class? Or should i create a new mapper and class to fit it? Both of the approaches seem to have drawbacks, separate class for each query is more work, but it makes sure you always know what data it contains, rather than checking for nulls or working with optionals, also it prevents you from mapping columns you actually don't need.
What is your opinion? Thanks a lot!
Technically you could reuse the same User class for full 15-attribute as well as partial 2-attribute entity. But that will come with a price. Every time you'll see an instance of User class in the code your will have to think if it's the full entity or the partial? Which fields may or may not be null? This will make it much harder to reason about code.
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 7 years ago.
Improve this question
My back-end calls for a dynamic datasource and topology, and my front-end calls for a bunch of app coding that queries the RDBMS. My idea is to walk away from the JDBC API altogether, as it turns out, for any API the app coding couples itself to.
Here's the design idea... On queries, the app code passes in SQL, and receives DefaultTableModel as a result. On updates, the app code passes in SQL (even batches of it), and receives success/failure code (plus error message) as a result.
Would you couple all of your app code to class DefaultTableModel? Would there be a better class for generic, decoupled query result handling? (If I ever need metadata, I can subclass/encapsulate that in with the result) Are there examples out there of this already being done? I do not need more than the above for this application. I don't have extravagant RDBMS needs.
What standard non-JDBC options does the Java API have for holding the kind of data in a ResultSet? I am aware of AbstractTableModel and DefaultTableModel. In any event, it has to be smart enough to associate a class with each column in terms of datatype.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Hey guys, I'm having a doubt about the implementation of class diagram above, confused between the Single_table strategy and the joined_table strategy, any help, any suggestion about the patterns followed in this case that are used to enhance the response time of the login process.
Any help will be appreciated.
Thank you guys in advance :).
If I got you right your concern is whether to us a table User with a flag of different Professor etc. tables. Well, I'd go for the single table. Actually there is not much difference in performance. In order to retrieve the professors from the user table you would need a WHERE clause while a native table has the records ready. The time difference in any case would be near to null as a RDBMS will handle WHERE clauses very effectively granted the DBA has set good indices. A single table is easier to maintain with respect to maintaining all the columns you need (but which your class diagram currently does not show).
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
In my web application i have a employee table with employee id,name,designation salary... as attributes which may contain thousands of records in it.. I want to search employee name, so for searching employeename which one will work faster hitting DB every time or create list of employee names once in java bean and iterating it for searching every time... Which one is better..??
By far, even if you have millions of records, it is better to hit the database per request. To enhance this, you can add a key/index on your name field in your employee table and the requests will be faster.
In case the data in your employee table doesn't vary that much, you have another option which is using a cache for your employee table. With this, your access to the data will be even faster since it will look up the employee at cache (usually RAM), but this comes with a more complex design and adding policies for your cache data retrieval and setting periods to update the cache data.
This is depends in few things..
Hitting the DB is IO action and in case you have specific screen/process that does a lot in specific flow of course it will be better to load list from DB once and use it several times, And this is in case that you can be sure that employees list won't be change in DB by other process/Or it can change and this is not critical for you..
If the screen/process make only few hits to get employees it should be hitting DB.
Remember that Hitting DB a lot of time can also load the DB and cause him to be slow.. He can't handle with infinite number of request.
Hope that helps