Tag Info

New answers tagged

0

On file size You need to deal with the vast array of issues that come from the sheer size of images - whether compressed or not, images range from hundreds of KBs and up - which is tens to hundreds times larger than the typical amount of data your frontend/backend handles per operation. Therefore, the first strategy is to focus on reducing the image size. ...


-1

I would only sync the URLs to the images stored on the server, not the complete image as BLOB. So the sync is fast and the images must be loaded 'on time' when they are used/displayed. Edit: I saw, that your first solution was something like that. So sorry, no news for you, but I still think lazy image loading should solve the problem...


2

You could do this by creating 2 additional tables: Table Images ( ImageID int, ImagePath varchar ) Table ImagesXUsers ( UserID int, ImageID int ) (or ImagesXPages or whatever it is you need to associate these images with) Whenever images are uploaded, they are inserted into the Images table, and are appropriately associated with the user account via the ...


2

You should assume that the server-side dataobjects use their own conventions, and the client-side would have its own. When fetching/posting data, you can set up a model adapter to handle switching between the two. By doing it at this level, each side uses their own conventions that make sense in each's contexts. After fetching your data from an ajax get, ...


3

General Uses If you have data structures that are not clearly defined at the time when you make the system. I tend to keep user settings in nosql, for example. Another example was a system where the users needed to be able to add fields at runtime - very painful in an RDBMS and a breeze in NoSQL. If your model structure is largely centered around one or ...


0

I would definitely use such a database during the planning stages of a project (before development, before even design) to record data whose structure, relationships, and characteristics are not yet known and subject to analysis. I would try to make everything fit a relational model after that.


0

In some cases, you won't need foreign keys. For instance: Find all the comments posted by this user can be as simple as loading the comments part of a document corresponding to a user. This is called denormalization: instead of having two sets with a join, you have one document and everything you need is inside the document. One query, no joins, better ...


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

Most people in production are painfully forced to keep things simple as the data size grows. There is normal form and non normal form in design and real world is a different animal. So you may not want a five table join in production. So in non normal form, one table. It is important to isolate the data changes so you are not forced to change the structure ...


0

Use a multidimensional array like $key => $value, $key2 => $value2 and iterate? $data = array( 'column_name' => 'value' ); querysorter ( 'tblname', $data ); function querysorter{ foreach($data) //bindparam here } Hope this helps, just had to do something similair.


0

good morning, i think this could part of the answer (SQL) : the last 2 queries give the top comment : the less the average the better the position (upvote = 1 and downvote = 2) CREATE TABLE t_comment ( comment_id INT NOT NULL , question_id INT NOT NULL, user_id INT NOT NULL, timestamp TIMESTAMP ); ALTER TABLE t_comment ADD CONSTRAINT pk_comment ...


0

Just explain to him that UTF-8 is the default for web traffic. And any user can enter any valid unicode character in their browser. Its just much easier to have utf-8/unicode all the way from front end to back end than to deal with the many and various issues that result from utf-8-> latin-1-> utf-8.


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



Top 50 recent answers are included