Tag Info

Hot answers tagged

123

Premature optimization is "optimizing" something because of a vague, intuitive sense that, y'know, this will probably be slow, especially to the detriment of code readability and maintainability. It doesn't mean willfully not following well-established good practices regarding performance. Sometimes that's a difficult line to draw, but I'd definitely say ...


47

monitor for slow queries once we go live because nothing says quality like making your users suffer for a lack of design! You should know which queries need indexes when you design the tables, you know which columns are being queried on in where clauses and joins. These should be indexed already because what might not be apparent in a live environment ...


22

"Premature optimization", in its derogatory sense, means costly optimization that might not be needed. It doesn't mean all optimization implemented before the latest possible point to prevent bankruptcy! In particular, it's legitimate to optimize based on performance tests before going live, to ensure you can meet some sensible (albeit approximate) ...


19

I feel this is premature optimisation because our application is not even released yet. I suggested to monitor for slow queries once we go live and then add indices accordingly. You can't treat your end-users and production environment like quality-assurance. In more words, you're saying that you'll figure it out in production. I don't think that's ...


5

Both options are over-engineered, involving the database is inappropriate here, and the directory structure is too deep. Instead, for administrator-friendly software, I see the following patterns emerging: Paths are configured in config files, not database. Usually, you want to be able to copy the database dump to another system. Often, the database ...


4

No, it is not premature optimization, but it must be done correctly as any optimization should be. Here is what I would do: Load the database with enough test data to mimic a production load. You cannot get this 100% accurate but that is fine: just put enough data in. Does one table have a fixed amount of data? Load it up. Do you have one table that holds ...


3

When your application is released, it is too late. But any proper development process should include performance testing. Use the results of your performance tests to decide which indexes to add, and verify their effectiveness by repeating the performance tests.


3

Are there techniques that can encrypt the data in such a way that a data breach on the server won't show the data in the database in clear text, but that multiple users of certain permissions can decrypt the data they need? Yes. You need two things: modify your existing table structure so that all fields that you want encrypted are appropriately ...


3

... table in my database named "users", which has their username/password/mail etc, Of course you mean that you're storing the "hashed" or similarly calculated value derived from the user's chosen password. How do I best store a users status? I would go with an Integer value in the users record, which is a foreign key to a (tiny, little) look-up ...


2

I agree with you, storing the status as integer will be enough. And I would prefer store it in different table, let's say user_status, since it will be updated frequently according to user activities.


2

Following proven patterns for known problems (like finding a record by its ID) isn't premature anything. It's just sensible. That said, indexes aren't always a straightforward business. It's often tough to know during the design phase which indexes your traffic will depend on and which will bottleneck write-operations. So, I'd argue for leveraging some ...


2

This doesn't call for a linking entity (although they very useful for N:M relations and infinitely better than trying to cram a list of things into a single field or multiple fields!). What you want is a SONG entity that can be referenced by multiple RECORDING entities. A SONG has a title, artist etc., while a RECORDING might have a bit rate, loudness, ...


2

There is no problem storing big strings or binary data. I worked with a database with more than one terabyte of binary data and worked very well (postgres) and the only bad thing was the backup time. The big question is: "Will you need do constant searches in this text?" If you are going to search for strings in the text, you can think in one index ...


1

Keep price range data in the PriceRange table, but store this information in the quotation also, using extra quotation detail tables if necessary. This is no different than any other ordinary invoice. The prices for each line item are always copied to the invoice line items, so that they reflect the price of the items at the time the invoice was created.


1

The users table is definitely the place to store it. Note that if you use MySql (and possibly some others?), you can also use an enum, so that you can be sure that the value that you write is in range, and you can refer it to it legibly in your application's code (e.g., onLine, instead of 1).


1

What you seem to need is an additional table mapping questions to a question group and another mapping question groups to recommendations. Based on that data, you could query the questionnaire and find all question groups that it completely matches. From this, you can derive your recommendations.


1

There are at least two aspects of database design that your question touches on. The first is the issue of class/subclass design. What is the best design for classes and subclasses when designing a relational database? (This issue is also known as types and subtypes or generalization and specialization). The second is the issue of representing a ...


1

I once worked on a system that modeled similar data. Not geographical, but hierarchical, where the hierarchy was not necessarily well-defined and entities might "skip" layers: A -> B -> C was just as valid as A -> C. Using separate tables is great when you can guarantee the data will match the structure, and in fact must match the structure. However, that ...


1

Yes is can be, but beware of the following: Recursive queries (For example, in Sql Server, common table expression (CTE) Recursion in code (self referencing objects) Both of these can be tricky to understand, implement, and support. For your queries, it will not be a simple Select * from Table type of query. Also, most likely the object model in ...


1

I do not think encrypting all the data in the database is a good idea, as it will be a major performance issue (especially when it comes to searching). Instead I'd suggest to implement application level security for users, and encrypt the database files from the operating system level or store them in encrypted file container such as (veracrypt / truecrypt) ...



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