Tag Info

New answers tagged

0

There should not be any significant performance impact A clustered index is basically free - why not use it? Insert check for unique is an index seek It is very very fast for single or composite key Even if there performance implication for me data integrity wins every time If the data has a natural composite key then you should use a composite key ...


3

The best option is the one with the fewest things that can go wrong. This is the "the web API converts the value and inserts it into the database." There is no significant amount of computation necessary, and changes are you don't even need to convert it into decimal first. You can insert using the unhex function in MySQL (docs). If you were going for ...


2

Option 1. The string data should definitely be processed into more appropriate data types before insertion. That measurements are provided in hexadecimal is a detail of data transfer, and isn't important when it comes to storage (hexadecimal being merely a representation of numbers). Note that the script wouldn't be converting the string data to decimal ...


2

Joins are not slow. They are incredible fast if you join to a primary key or indexed column. You should not make design decision from the assumption that joining is a problem. Now, there may be particular cases e.g. with very large datasets or distributed databases, where joining may be a performance problem, and there are various ways to mitigate that ...


0

I would go even further: User: Id, Name, WallId Post: Id, Content, Title, WallId etc... Wall: WallId Group: Id, Name, WallId... Basically, post belongs to a Wall. Wall can belong to a user or a group.


2

Any thing ("Entity") that can exist on its own, independently of anything else, should have its own table. User: id, name, hashed_password, join_date, birth_date Group: id, name Relationships between things require generally require "linking" tables. Post: id, user_id, group_id, post_date, post_title, post_content The key to success is proper ...


3

The usual practice is to distinguish between the login name, (often the users email address), and a display, or nickname/moniker/handle, which you can allow/force the user to input themselves. The session management then uses the login name for all transactions, (usually via a per session hash to avoid people being able to recover the actual login name), ...


1

Migrations should change the data when needed - otherwise they don't fulfill their purpose of taking a database that works for an old version of the application and making it work for newer versions. Migrations are also the best place to do this, because you can make assumptions on the database's structure before and after the migration is run. One thing to ...


2

That is relatively safe, providing that you use SSL (HTTPS, use ssllabs to check the security of your site), and you configure your cookie to be domain-specific, have an expiry date not too far in future and be "HTTP-only". Use mcrypt for encryption (there's support for that in PHP) and the salt key should be reasonably long, and kept SECRET, or change for ...


1

To start off with your login, I'd like to say that the password should be stored safely as well(This is probably not your main concern). Whenever you use sessions or cookies, you're vulnerable to session hijacking. Now on that link, there are ways to prevent session hijacking as well. Like: Encryption of the data traffic passed between the parties by ...


3

It is no problem to have data "not consistent across all rows" in a relational database. This is precisely what relational databases are designed for! You create a table for the data which is common across all activities, and then you create separate tables for data specific for kind of activities. E.g. a football table with a score column, a cycling table ...


3

Take a look at PostgreSQL. You can store JSON in it in a type-safe way. It supports indexing so you can combine relational data with JSON documents pretty well. It is also fast, there are plenty of benchmarks. Also, if you never used NoSQL before, please read this: Why You Should Never Use MongoDB (don't mind the title, article is pretty constructive) As ...



Top 50 recent answers are included