Say you have a table meal that you have been using in your application for many years. You have always been using this table to serve meals. But now you need to be able to make meal drafts before they are (optionally) made. So you add a new boolean column draft to the meal table; these meals are not to be served since the user has not confirmed that they want to make this particular meal. So they need to only be available in the draft dialog and nowhere else.
The drafts need to be persisted since a user might close the dialog and want to get back to the preview later.
Actual meal serving is still the backbone of your application. So now you need to update all of the queries to check that this flag is false. This is a lot of work and you have to be very careful, since forgetting one query might turn into a pretty subtle bug.
You could perhaps duplicate the meal table creation and make a new table called draft_meal, but this is the central table in your application (related to many other tables) and you have to update meal to add things like new columns etc. pretty regularly.
Is there another way to deal with this? Is there a way to deal with niche flags that “pollute” the whole application?
You can change the name of your existing table to something like meal_master as you add the new column. Then create a view something like this:
CREATE OR REPLACE VIEW meal AS
SELECT col, col, ...
FROM meal_master
WHERE draft = 0
That approach allows you to keep your existing code going as you add your new feature. You can go live with less risk to your existing service.
You should still refactor everything to use the new table; you just don't have to do it in a big bang.
Make sure draft's default value is 0.
You're learning that data lives longer than the code that uses it.
Related
In an mysql table I would like to get data from user, however the data would need to be moderated by admin first. My question is that is it normal to just insert into the original table and use a field as flag of the moderation status? Or have a separate table of pre-moderated posts and do the insertions only at moderation?
I think both method would work but I am not sure if I miss out other considerations here. Hope someone experienced can tell me the established/preferred way to do that.
If you're working with a not-huge data set I'd recommend just adding a flag column that allows you to show or hide user data. This will require fewer and easier queries to work with and should make your life a lot easier than juggling the data between multiple identical tables. Additionally, if you want to add something like a button for "report this content as BAD" you could remove the content from other results while only "soft deleting" it from public visibility.
I use access to store concert registration information at the non-profit I currently work at. I have it set up so that I dump all of the patron contact information into one table, and all of the concert registration information into another. when we change our concert season, I simply copy/paste the "2012-13 concert registration table" and rename it the "2013-14" concert registration table".
the concert registration table serves as my "hub" for all my other information. I have about a half-dozen summary queries that show information for specific concerts, who I still need to collect payment for etc. as well as many Word mail merges associated with each document. This setup works great, except that every season I need to go in and re-link all of the queries and word docs to the new registration table
I will be leaving my job at the end of next month, and I would like to make the database more user-friendly, especially since I am fairly certain that my replacement will have zero familiarity with access. my questions are:
1) Is there a more elegant, easy way to transition from season to season other than to create a new registration table and subsequent queries from year-to-year?
2) How can I idiot-proof this database for the new person when I'm gone? I'm scared that if I create an extensive "how-to" guide, it simply won't be read and the person will be forced to reinvent the wheel. I'm toying with creating a switchboard, but I'm scared that this will make the database seem more unapproachable.
Thank you for your insight, happy to clarify if there are any questions!
Just make 1 table. Call it "registration table" and add a new field called Season. Your queries will be include a filter for that field. Then you won't need to relink your queries, copy tables, etc.
For an example, say you have a query to pull all the information from that table for a particular season. It might look something like:
Select * from RegistrationTable where Season=[What Season];
When run, the query will prompt the user for the season and pull only that data.
Also, I do recommend the "how-to" guide. There's probably a lot of manual manipulation of the database that you do and don't even think about. And if nothing else, you can always say you gave them documentation and thus provided for your successor.
This is for a CRM application using PHP/MySQL. Various entities like customer, contact, note, etc, can be "deleted" by the user. Rather than actually deleting the entity from the database, I just want it to appear deleted to the application, but be kept in the DB and able to be "restored" if needed at a later time. Maybe even add some kind of "recycle bin" to the app.
I've thought of several ways to do this:
Move the deleted entity to another table. (customer to customer_deleted)
Change an attribute on the entity. (enabled to false)
I'm sure there are other ways and that each have their own implications on DB size, performance, etc, I'm just wondering what's the generally recommended way to do something like this?
I would go a combination of both:
Set a flag deleted to true
Use a cronjob to move the entries after a while to a tabelle of type ARCHIVE
If you need to restore the entry, select into the article table and delete from Archive
Why i would go this way?
If a customer deleted the wrong one, the restore could be done instand
After a few weeks/month the article table may grow up to much, so i would archive all entries that are deleted for 1 week p.a.
A common practice is to set a deleted_at column to the date at which the entity was deleted by the user (defaults to null). You may also include a deleted_by column for marking who deleted it. Using some kind of deleted column makes FK relationships easier to work with since these wont break. By moving the row to a new table you would have to update FK (and then update them again if you ever undelete). The downside is that you have to ensure all your queries exclude deleted rows (where this wouldnt be a problem if you moved the row to a new table). Many ORM's make this filtering easier so it depends on what you are using.
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.