Tag Info

Hot answers tagged

8

But is that really important? Consider that the UI has to make a network call to the API; that's pretty big (order of magnitude of milliseconds). Databases are optimized to keep things in memory and execute reads very, very quickly (eg. SQL Server loads and keeps everything in RAM and consumes almost all your free RAM if it can). The Logic In ...


7

There is nothing wrong with providing an individual organization for each freelancer, even when there is only one "employee" in this organization. Actually, this reflects the legal situation much better, since a freelancer can have the role of a company (own address/mail account / phone number) and the fully separated role of a private person or employeed ...


5

http://www.oracle-base.com/articles/12c/identity-columns-in-oracle-12cr1.php The 12c database introduces the ability define an identity clause against a table column defined using a numeric type. The syntax is show below. GENERATED [ ALWAYS | BY DEFAULT [ ON NULL ] ] AS IDENTITY [ ( identity_options ) ]


4

Yeah, don't do that. A typical approach would be to have a LoadUser($user_id) function. It will return a user with all its attributes loaded from the database. Hence, load all the attributes of the object when you first create it, don't try to lazily load each attribute one at a time. It will be simpler and more efficient. When you want to save it, either ...


4

Return the harshest, unfriendliest result possible in the event of a malformed request (one that returns more data than your metering allows is malformed). I suggest returning a 4** error code. Then, also provide paging parameters, so that users may request pages. oData has this feature, for instance. Do not truncate the data silently, under any ...


3

At first blush, I would say two things would make things simpler: Create an Organization that represents "Freelancers" and assign all freelance Contacts to that Organization. and An Invoice should contain both an OrganizationId and a ContactId, which represents the Organization and Contact relationship at the time of the invoice. If the Contact changes ...


3

In general, you can't test each method separately. At a minimum, each test will be testing both a constructor and the method you actually call. For methods that change the state, you are going to have to investigate the state afterwards. You can either have the test depend on implementation details by looking into the internal state of the object, or you can ...


3

It depends - mainly on the life cycle of your database(s) and the usage scenario. Creating the DB structures automatically makes sense if the database is used exclusively (or at least primarily) by your application you expect to have not just one database, but many different db instances of this structure in different places the database is used as some ...


3

a) ii) is pure idiotic, evil stupidity. Don't. a) is better if you want to code the simplest possible thing (which is usually a very big 'want'). b) is better if you're pressed for database space or absolutely have to minimize DB access time, and don't care about the additional logic your code needs to retrieve the numbers. (Cell phone numbers aren't that ...


3

Is it really a big performance issue to make multiple tables with unique columns. I have heard indexing columns help quite a lot? This depends on the DB system. Almost any relational DB system I know of automatically will add an index for primary keys. Some DB systems also add indexes automatically for each FK constraint, some others do not. For foreign ...


3

Loading the data to memory in a sane manner is the job of the database engine... You DO NOT need to manually perform that task, your database engine will perform that task for you, its purpose is to process queries and cache the required data. Unless you are firing 1000's of queries a second, dont be afraid to fire multiple queries to a database, it is ...


3

The time taken to query a local database on disk should be orders of magnitude less than the time required to backup a file or communicate over the internet. (Your database isn't on the online server, is it? In which case keep a cached copy locally - assuming this isn't shared between users. Use a version number to check that the local host is using the same ...


2

What database capabilities are needed depends on the application. There are applications which only read data but don't write any. There are applications which only write data, while the reading is done by another application. There are applications which read and insert data, but must by specification be unable to ever update or delete any data, ...


2

DB systems are fast. Unless you are doing something like web portal for many schools to use your software on the same platform, you should usually have no trouble with a regular HW (provided that you generate the queries in a somewhat sane manner). That said, if you still have doubts it is not that difficult to create an script that will populate your ...


2

We can't tell you. We don't what your queries look like. We don't know how long they take to complete. We don't know how much overhead is involved in each request to your API server. We don't know how geographically dispersed your clients are. Etc. If this is a scenario that requires optimization and is one in which you can decide whether to split or join ...


2

Sounds like your team is optimizing before they have a reason to. Have you measured time to execute these requests? Chances are forcing this paradigm will create worse performance for the end user as the round trips to the web server will have a much higher latency than the connection time from the web server to the database. On top of that most web ...


2

There are several sides to unit-testing: Unit-testing is meant to give you confidence that a component works as it should and that future changes don't break any of the current functionality. Unit tests should be fast enough that you can execute them often without it feeling as a slowdown in your workflow. How fast they should exactly be and how often you ...


2

It's generally considered a good idea to separate the environment setup from the main application. The usual practice for something like this is to have the database structures created by your installer or setup script. The application should not create its own structures, if it can help it. One reason to separate them might be if you have slightly ...


1

It is not true that most relational database technologies only support adding items one at a time. Most major RDBMS have a bulk insert or load command that adds many rows at once. This is much more efficient than calling insert over and over again. Thus, any CRUD interface that needs to handle loading large volumes of data should have some mechanism for ...


1

From personal experience I suspect you are approaching it in a sensible way - there would be a performance hit by using the RESTful API for 'internal' access. However, what you might consider is building an internal linking library that takes internal requests to access the DB and convert it into a form that is essentially what the RESTful API uses ...


1

Short answer - yes it does. If you test remove with something that involves getById and test getById with something that involves remove then both may fail simultaneously and you will not get any indication. The straightforward solution is to just not use any other functions in the test. For example - by using plaintext queries - since you know your test DB ...


1

To expand on what @joshin4colours said, I think you have a false dichotomy (trichotomy?). Why not provide all three solutions? Maybe the default is to return a 413 but with other flags you can either get some of what you want with an embedded error in the data and/or provide a way of batching the data. It really depends on what your specific ...


1

Multiply each value with a weight, the timestamp will be small while the number of upvotes will be large.


1

Two thoughts: First, to the consumer using the API, he is making one call to accomplish a task. What happens after your server receives the call to fill the request should not be so rigid. If that one call from a consumer requires 10 sub-work items to pull the data together and return it, then that should be acceptable. Second: Do you see an actual ...


1

I hacked a basic example with Mysql Workbench in 5 minutes You can have different methods to keep track of borrowed and returned, I showed an example with borrow_history to keep history and you can manage if library_items are out or not via "borrowed_until" field. You can also track how many books a student took out via "borrowed", that you can += 1 upon ...


1

1 -- should not be a problem until you hit millions of rows. Generally speaking you should start out with a clean "logical" schema and change it when and if you hit a performance problem. 2 -- Views are just "canned sql" querying a view is no different from running the underlying SQL. There are good reasons to use views but performance is not one of them. ...


1

There are 2 entities. One is admin. The task of admin is to define slots for appointments which will be taken by applicants. admin sounds more like an user that an entity. Of course, user may be an entity (or not if your model does not incorporate authorization information). I see many nouns there : "The task of admin(user) is to define slots for ...


1

Depends on a few more details you don't give, eg expected size of data. But in general I would most likely go for a)i) a)ii) would only be an option if you would talk about some database system that has special features to store and query this like some NoSQL databases (and maybe Postgres to some degree), having the option to actually query this data and ...


1

The only solution I've found is to have a functional layer between the DB and the application. Data needs in the application require abstraction from the DB schema and vice versa, lest a change of schema become massive project surgery. This is not the same thing as using an ORM. If the DB schema should be changed then the change must be accompanied by ...


1

The priorities of Oracle are just way different from the once of the everyday developer. From my experience I'd categorize Oracles attitude as follows: Top Priority Reliablity: If one thing makes you look bad in the RDBMS world, it is destroyed data, broken backups and select statements returning wrong data. Performance: The customers that pay really big ...



Only top voted, non community-wiki answers of a minimum length are eligible