In this page, you can see what I mean,
http://codex.wordpress.org/Database_Description#Table:_wp_users
It only creates a normal index for the user_login column while I think an unique index should be created for it.
Well since the unique index (primary key) is the ID column, the coder probably didn't see the need to define another column in the table as unique. As you point out, though, user_login column is indexed so that gives the performance advantages when querying that table.
Don't know wp, but maybe it needs to allow for multiple user_logins with different user_status?
Related
I want to check if some attribute values have changed after editing a Variant group in Akeneo V. 1.3.
Unfortunately I am a little bit lost: Is there a way to get from a Pim\Bundle\CatalogBundle\Entity\Group to the attribute values? Is there another better way to get these values of a Variant group that was edited?
I cannot even find out in which table the attribute values are stored in MySQL (I've just found pim_catalog_product_value for the product values).
Yes, it's not easy to dig into this part.
The values of a variant group are not stored in the same way than the products values.
These variant group values are only used to be copied in related products and are stored in a product template.
From a product template, you can fetch the values normalized in json with
$group->getProductTemplate()->getValuesData()`.
You can take a look on ProductTemplateApplier and ProductTemplateUpdater to see how we apply variant group values on products (json format is useable almost directly with product updater).
When we edit a variant group, to be able to use the same form than for the product, we use a subscriber TransformProductTemplateValuesSubscriber.
It denormalizes json values to product values objects with
$this->denormalizer->denormalize($data->getValuesData(), 'ProductValue[]', 'json');`
Don't hesitate if you need any further information.
I'm struggling to decide what database schema to use. One large table, or many small (though more difficult to manage).
I have 10 templates each with their own text fields. I am trying to store the text for the templates in a database and then when the web page is called I will show the correct text in the html template. Because a mixture of these templates are to be in a sequence of screens where you can navigate backwards or forwards, I need to be able to sequence them, I can only think of adding a page_number column. I also would like to re-order them and delete them as necessary using the page_number column.
I was planning to do all this in a web application without the need for a standard folder/web page structure, like a small CMS system.
option 1,
I can create one large table with many columns, lot's of which will be empty, over half with each row. Is this bad?
option 2,
I could create many tables using only the relevant template columns required.
The problem I see with this, is the headache of repopulating a column in each table when I delete a row, because I need to re-sequence a column that represents page numbers. Which I reduce if I use one large table.
I've thought of moving page numbers into another table called page_order but I cannot think of a way to maintain an effective relationship between the other tables if I make changes.
I'm yet to figure out how to re-sequence a column in a database when a row is deleted. Surely this is a common problem!?
Thanks for taking the time to help!
Have one table that contains one row per template. It might look like:
id (INT, auto-increment)
page_order (INT, unique key here, so pages cannot have the same number)
field1 (STRING, name of the text field)
value1 (STRING, contents of the text field)
field2
value2
Then you have to decide the maximum fields that any page can have (N) and keep adding field/value columns up to N.
The advantage of this is you have one table that isn't sparsely populated (as long as the templates have about the same number of fields, even if the names of those fields are different).
If you want to make an improvement to his (maybe not necessary for a small amount of data) you could change field to an INT id and connect it to a lookup table that contains (field_id, field_name).
I'm creating some url rewriting for asp.net. Now I am tobbing if I should include the id in url or just the title. Do you guys know if it's a significant performance hit to lookup an item by title instead of id?
If you can, lookup by the primary key, which is probably ID in your case.
However, if your titles are unique and you have an index on Title, the performance difference should be minimal.
Edit : Since is URLwriting, the title probably has better SEO mileage, FWIW
It depends on how many rows you have in your table and many other factors but generally if you have an index on your title column it shouldn't be too much of a performance hit. Ultimately the only real way to see if it's a problem in your scenario is to try it and run some tests.
The most important factor is to make sure you have have index on the column you are attempting to do the lookup on. So another way to say it is put an index on the columns in you where clause.
Enjoy!
That depends.
If the Id is the used for clustered id (default form PK) so the difference can be significant,
because in simple words, If you are using a clustered index to retrieve the data you do less operation.
The numeric type vs character. That also depend of the size that You have declared for this type. NUMERIC(20) is slower than VARCHAR(5).
In a specific table I have a SortOrder integer field that tells my page in which order to display the data. There are sets of data in the this field (based on a CategoryID field), and each set will have its own ordering. Users can add/remove/update records in this table.
My question is what is the best way to manage this SortOrder field? I would like to "reseed" it everytime a record is deleted or updated. Is this something I should be using a trigger for? Or should my code handle it and manage the reseeding?
What I used to do is use only odd numbers in the SortOrder field so upon changing the order, I would add or subtract 3 from the current value of the modified item and then do a reseed (order the items again using odd number indexes). Also I used to reseed after every insert or delete.
All you really have to worry about is swapping any two fields. All new entries go to the end and i'm sure you've got a mechanism by which the user can change the order. The order change, move up or down, really is a swap with a neighboring field. All you really care about is that all the fields are sorted properly. Don't let a mathematical sense of aesthetic drive you into creating something overly complex. (You'll end up with holes in your sequence after deletes are made but that's OK. It's an internal sequence marker used for ORDER BY. the numbers don't need to be made contiguous.)
I'm looking to create a table for user preferences and can't figure the best way to do it. The way that the ASP.NET does it by default seems extremely awkward, and would like to avoid that. Currently, I'm using one row per user, where I have a different column for each user preference (not normalized, I know).
So, the other idea that I had come up with was to split the Preferences themselves up into their own table, and then have a row PER preference PER user in a user preferences table; however, this would mean each preference would need to be the exact same datatype, which also doesn't sound too appealing to me.
So, my question is: What is the best/most logical way to design a database to hold user preference values?
Some of the ideas that I try to avoid in database work, is data duplication and unnecessary complication. You also want to avoid "insert, update, and deletion anomalies". Having said that, storing user preferences in one table with each row = one user and the columns, the different preferences that are available, makes sense.
Now if you can see these preferences being used in any other form or fashion in your database, like multiple objects (not just users) using the same preferences, then you'll want to go down your second route and reference the preferences with FK/PK pairs.
As for what you've described I see no reason why the first route won't work.
I usually do this:
Users table (user_id, .... etc.)
.
Options table (option_id, data_type, ... etc.)
(list of things that can be set by user)
.
Preferences table (user_id, option_id, setting)
I use the new SQLVARIANT data type for the setting field so it can be different data types and record the data type of the option as part of the option definition in the Options table for casting it back to the right type when queried.
If you store all your user preferences in a single row of a User table you will have a maintenance nightmare!
Use one row per preference, per user and store the preference value as a varchar (length 255 say, or some value large enough to meet your requirements). You will have to convert values in/out of this column obviously.
The only situation where this won't work easily is if you want to store some large binary data as a User preference, but I have not found that to be a common requirement.
Real quick, one method:
User(UserID, UserName, ...)
PreferenceDataType(PreferenceDataTypeID, PreferenceDataTypeName)
PreferenceDataValue(PreferenceDataValueID, PreferenceDataTypeID, IntValue, VarcharValue, BitValue, ...)
Preference(PreferenceID, PreferenceDataTypeID, PreferenceName, ...)
UserHasPreference(UserID, PreferenceID, PreferenceDataValueID)