Tag Info

Hot answers tagged

119

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 ...


110

Unicode is certainly difficult, and the UTF-8 encoding has a couple of inconvenient properties. However, UTF-8 has become the de-facto standard encoding on the web, surpassing ASCII, Latin-1, UCS-2 and UTF-16. Just use UTF-8 everywhere. The most important reason why you should support Unicode is that you shouldn't make unnecessary assumptions about user ...


54

I think beyond the technical question, your boss may not have the time to keep up to date on current standards. Since his stance is not completely out to lunch, just out-dated, respect his position when discussing this matter (and you need to remember to discuss, not argue), and try to work through concerns he has with regards to UTF-8. I suspect the ...


46

Which of us is right? Once upon a time, your boss was. But as time goes by, things change. Nowadays, you are (but before running to your boss, be sure to read Nelson's answer too). Old versions of MySQL, and old versions of mostly everything, dealt much better with the older Latin1/ISO-8859-1(5) than UTF8. There is a reason why UTF8 has been created, ...


45

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 ...


21

"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 ...


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 ...


4

Some situations where restricting the character set only to ASCII may make sense is for limited choice fields, e.g. status fields, because you strictly control the values that can be there, and foreign key/references to external system, because there are rarely any reasons for them to have anything but alphanumeric characters and a few symbols. For any ...


3

Although you could avoid "SQL injection" attacks by not using a relational database or not using SQL to query one, they are really part of a broader range of untrusted user input attacks that need to be protected against. Even if you had a NoSQL key / value pair store you could still be vulnerable to an attacker deleting all the data in your store. The ...


3

You should define permissions for roles, not users. Users are assigned a role which specifies the type of access it has on a given page. Take a look at the following diagram: Good examples for roles might be "manager", "admin", "user", "public". The advantage of doing it this way is that roles are easy to change later. If you add a page and decide ...


3

Similar to the answer by jmoreno, you can deny a user access to everything aside from EXECUTE permissions on stored procedures, then take advantage of ownership chaining to have the stored procedure perform the required operations on the tables. See here for details https://msdn.microsoft.com/en-us/library/bb669058(v=vs.110).aspx When the user enters their ...


3

To begin with the answer, it doesn't matter, how your server is configured. The character encoding in MySQL could be configured per-column (means, same table could hold characters in multiple encodings, easy). I.e. my server (and a number of legacy databases in it) is configured for cp1251 by default for old clients that unable to set correct collation upon ...


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.


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

Adding a "tenant" column (ClientId in this case), and using that to filter by tenant, is logically identical to having a separate database for each tenant. The only difference is, you have to remember to use that everywhere. This is true for everything in the database, not simply your nested sets. You are safe, assuming you are careful in writing the stored ...


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

Don't store passwords in a database, even encrypted passwords. Authentication and Authorisation are different concepts and unless space efficiency is very important in your database, you should consider splitting them up. Instead of having a column for each type of permission and what object that permission relates to you should take a look at encoding ...


1

"Good", "easy", and "efficient" are not only all subjective and ambiguous terms, very often they are in conflict with each other. Choosing a data representation is virtually always a trade-off between goodness of one kind and another kind. Having separate fields for every read/write/edit right for each page makes for the simplest database layout: just a ...


1

You might want to look around the System.Web.Caching documentation on MSDN. There are a few good abstract ideas about Caching data that are relevant to any system including outside of a Website. For example, the CacheDependency class: Establishes a dependency relationship between an item stored in an ASP.NET application's Cache object and a file, cache ...


1

I think Jon Raynor makes a good point about the safety and consistency of your data being better in a database. I think a database could make application management easier in some ways (fewer data files to be concerned with, as well as easier disaster recovery or failover capability) But, I don't think a relational database (such as MySQL) is required for ...


1

If this process really does take a long time, you could also consider moving the long-running work out of process. For example, when the request is handled by your Web API, you could write a message into something like a Message Queue and have MSMQ on the server activate a separate process to perform whatever work is indicated by that message. How that ...


1

Your three steps belong in the Model, not the Controller. If it's a long-running operation, make it an asynchronous one. See Using Asynchronous Methods in ASP.NET MVC 4 and C#5, ASP.NET MVC 4, and asynchronous Web applications for more information.


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

Storing files in memory doesn't seem such a bad idea if there are only a few of them. 1Mb of data isn't very much on modern servers so it's all down to the level of simultaneous users you have and what happens when you 'run out' of memory. In my experience I try to reduce the memory footprint size of each web service request because the server is usually a ...



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