Can't find any information about the number of labels allowed for the contacts. There are limits for the labels in mailbox, which is 10.000, but there's no information about contact groups/labels limit on the contacts.
Related
I'm writing an app that stores messages sent to users in a mysql database. These messages can have keywords that will be replaced by users data. at this time the dilemma that exists is what is the best way to store messages.
I have two options:
Store the original message (including keywords) in a table, and recipients in another. when i need to get the message, can be processed before it is displayed. the biggest problem is that the message will be different each time the user changes his own data.
Store the original message (including keywords) in a table and another table to store the recipients and the message the user is received. the disadvantage is the possible duplication of data, which can be a headache if the same message is sent to 20,000 users.
I would suggest several tables.
message - table, which will store message text
user - table to store user account information
mail - table to store message_id, user_id_from, user_id_to, is_read and other attributes to be associated with the specific conversation.
In a message table you should store message templates. When the message is fetched for display, it should be rendered. If you will need caching, you will be able to add rendered version of a message to the mail table (if rendering will consume too much of the resources).
Suppose I have an app that send notifications to users through GCM. Each user can choose out of several topics that it can be notified about.
I have a user table in which I store the GCM registration IDs of the users in addition to my own user_IDs, and I have a topic table where I store the available topics to choose from.
I also have a user_topics table where I store the user ID and the topic ID, so when a user choose a topic, it inserts a row to that table with the user ID and the ID of the chosen topic.
When I send the notifications, I query the user_topics table for all the user IDs that are assigned to the topic which I notify about and then query the user table to get the respective GCM registration IDs.
This can triple the duration of the notification sending process compared to a case where I would store the registration IDs not only in the user table but also in the user_topics table so I wouldn't have to query the user table when sending.
I know that a good practice is to store the registration IDs in the user table only, but in the notifications world the most important thing for me is to send the notification in the shortest time possible.
Will it be right to store the registration IDs in the user_topics table to shorten the sending process?
The API calls require a survey_id.
There is a surveyID in the web link but that is an alphanumeric code that is not the same as the survey_id. eg https://www.surveymonkey.com/s/STB97HW is surveyID 47481373
The "Edit survey" pages do not show the surveyID. (by the way, I've just found that the category eg "Just for fun" is another one of those survey attributes not returned by get_survey_details)
So a user can not make a note of the surveyID for later querying.
A user can download a CSV file of data, as a pair of "Sheet_1.csv" and "Collectors.csv" but neither of those files contain a surveyID. It would be a useful enhancement if, given a data CSV download, one could query the surveys list to find the one that has a given CollectorID.
The user could copy the survey title into a query and search the survey list for ones that match, assuming they copy it correctly or spell it correctly if entering it. Or the query could be by a date range, to get a list of surveys, present them to the user, and ask them to pick the one they want.
Is there no way that a user can discover a surveyID, either when designing the survey or when it is closed, in order to uniquely specify it for retrieval without having to go through this search process?
You need to use the "get_survey_list" API to get a list of survey ids, you can then feed these into the other API methods.
Note that a survey link is actually an individual collector for that survey, and not directly associated with a survey - i.e. it is associated with a collector, which is then associated with a survey. You can have multiple links (or collection methods) for one survey that way. You can get a list of collectors for a given survey using get_collector_list. get_collector_list can also return the list of URL links for these collectors, if they exist.
There is currently no way to get a survey_id without going through this method - these survey ids are not meant to be visible to the end user, usually for API integrations a list of the user's surveys is presented to them (via the get_survey_list method) and then they select one. If you're interested, have a look at Mailchimp, Zendesk or Hootsuite's integrations.
I had a question about the best way to handle this type of data.
In my system, I will have many users and many accounts... users are able to belong to many accounts, and accounts will have many users. I'm guessing the best way to accomplish this is with three tables
users
accounts
& users_accounts
my question is, when someone signs up for a paid account... where should I store the flag that distinguishes between regular users of an account and account holders? Should there be an owner flag in the users_accounts table?
Can I assume that one account cannot have more than one user (1-to-many relation)? In that case, two tables would be sufficient:
users
accounts
Where accounts contain a reference to a user id. A separate relationship table would be superfluous when there is no many-to-many relation.
Then the question arises: can a user have both paid and unpaid accounts? If so, the flag belongs in accounts. Otherwise, it belongs in users.
Taking your clarification into account, your three tables design is appropriate. The answer to your question then completely depends on how you want paid accounts to work.
Will a paid user have extra functionality in all accounts? Then the flag belongs in users.
Will any user have extra functionality in a paid account? Then the flag belongs in accounts.
Will a paid user have extra functionality only in paid accounts? Then the flag belongs in users_accounts.
If every account has only one owner, then you should put a user id representing the owner in the accounts table.
Users table will have only the user related data... name, surname, etc...
accounts will have the info of the account... type and any other data...
The key is that users_accounts is a relation table between Usersand accounts so it will have any linking data from the Users to the accounts and THERE you should put the flag because is there when you set the relations.
Add a paid flag to user_account.
Example Attributes:
user (id, name, street ...)
account (id, name ...)
user_account (user_id, account_id, paid)
You can tell by the paid column if the user is a premium account member or not.
This might not exactly be a "normalization" question, it's more the type of data which I am saving.
I've just done a specification for a messaging and email system . The idea is that I need to save all of the messages which are internal to my web service, but also know if an email has been sent with that message.
Here is the specification.
Specification
Any messages are stored in one table.
Messages can be from unregistered users, or registered users.
An unregistered user message will just have a return email address
A registered user message will have the user id of the sender
Messages are either owned by a User (meaning that they are the sent to) or messages are shared by user roles.
When a message is owned by a user, we record some information about this message (same table as the message).
a) Has the user opened/read the message?
b) Was an _email sent_ to the owner of the message or is it just an internal message
c) Date the message was first read
d) Date the message was sent
When a message is sent to a group of users, meaning that they are sent to "All Users", or "All Owners" or "All SuperAdmin"...
a) The message is saved once in the messages table with a sent date
b) Each individual open is tracked in a seperate table
c) A field records if a direct _email has been sent_, or if it is just saved internally in the system. (seperate table)
Messages can be threaded, this means that if a message is responded to, that it is a child or the original message.
Messages have different "Types", meaning that a message can be "System Notice", "Enquiry", "Personal Message", "Private Message", "Transactional Information"
Messages which are linked to an enquiry for a product, will save the ID of the product they are enquiring for. (ie The relevant property).
End Specification
Now the actual question...
As you can see in bullet 1)(b) I am recording for a message which is sent to an indiviual user, if an email was also sent for that message.
However, when an email is sent to a group of users, I am then recording whether an email was sent in a completely different table.
Obviously because I can't save this information in the same table.
What are your opinions on this model. I'm not duplicating any data, but I'm seperating where the data is saved. Should I just have a email_sent table to record all of this information.
It is hard to say whether your current design is good or bad. On the surface, I think that it is a mistake to separate the same piece of information into two places. It may seem easier to have a note about an individual email sent in the table which is closer to the individual and notes about emails sent to groups closer to the groups. However, your code is going to have to go looking in two places to find information about any email or about all emails in general.
If the meaning of the flag email_sent is the same for an individual user as it is for a member of a group of users, then looking in two places all the time for what is essentially one kind of information will be tedious (which in code terms comes down to being potentially slow and hard to support).
On the other hand, it may be that email_sent is something that is not important to your transactional or reporting logic and is just a mildly interesting fact that is "coming along for the ride". In this case, trying to force two different email_sent flags into one place may require an inconvenient and inadvisable mash-up of two entities that ought to be distinct because of all of their other, more important attributes.
It is difficult to give a conclusive answer without having a better understanding of your business requirement, but this is the trade-off you have to consider.
Create 3 tables:
MSG with id (key auto), msgtext, type (value U or R), userId/roleId
ROLES with roleId, userId
ACCS with userId, MsgId, date opened, read, etc
MSG records the message, with a type to see if it's from a role or unregistered user
ROLES points one role to many users
ACCS records everything, for a user, registered or not.
To retrieve, join the MSG type U with ACCS
join MSG type R with ROLES and then with ACCS
To retrieve all, UNION them