I am working on a website which utilizes a table for presenting old and newly passed laws. As such it requires that we have a large volume of data in the tables, and we constantly have to add more data to the tables.
I know already how to construct the table through CSS and HTML; however, due to the sheer volume of data which we are dealing with, I would like to know if there is a way to create a separate admin page where we can just plug in the law information and have it automatically added to the table rather than having to physically code in all of the information through HTML.
I also have a second question: I would like to add some tabs at the top of the table which allows users to sort laws based on the year they were passed. An example of this can be seen at this site: CT Legislation | 2014 | General Assembly | Passed | LegiScan . It has several tabs at the top which allow users to sort legislation- my question is what coding language is required to add this to a table?
A CMS may or may not do it for you. What really would be good is to use Parse to hold all your data. Take a look at Data Storage and Cloud Code. You can add new laws whenever you want, and you would configure Parse to dynamically add the data to your table for you.
You can use a variety of languages for this type of solution. If it were all web based it would likely utilize php for building a password protected page (admin) page. It would also be used along with SQL to send/receive data from the Database, the it could use CSS/html for the table and content styling.
For the database you could use MYSQL (a type of database).
If this is beyond what you are comfortable with, a content management system (CMS) would be a great option. They set up the entire backend for the user and have an interface that will allow someone who knows zero code or html/CSS to put a pretty decent website together.
The great part about using wordpress is it lends itself well to someone looking to learn more about development. You can see how things can be set up with code to achieve certain outcomes and can learn more and more as you work with the system on increasingly deeper levels.
Another option is using google drive. There are tabs, a table and it is cloud based so you can share it with people you want to have access to it. Anyone you choose can add/delete and it keeps very good track of what is changed and who made the changes. It is really easy to go back an fix things if they have been messed up.
Related
Please I am creating a database system for a group,using mysql and php.I am faced with some challenges,these are
1.I want to make the database system dynamic - thus where an administrator using the system would be able to add columns to a specific table from the front end without having to know something about mysql and php.
2.Also,I want the administrator who is ignorant of mysql and php, to be able to add tables to the database through the front end (PHP page).
3.With the aforementioned problems in (1 and 2), how would I make the columns added by the administrator appear on a form (php page) from the database, and how do I check for errors on the form.
Please these are instances to clarify what I have said.
a.What should I do to make a client add columns to an existing table in the database without any assistance from the technical team?
b.What should I do to make a client add tables to an existing database without help from technical team?
c.How do I output columns added by an administrator to a form and also check for errors on the form (php page) .
Any help is welcomed.Thank You
Well basically you can just write queries like ALTER TABLE xxx ADD column VARCHAR(100) etc. filling in the desired values from a form. This is, however, strongly discouraged. Not only would this mean your script would be able to execute queries which normally can only be executed by (mysql) users with administrator rights, it is also very susceptible to security problems.
Reading your question immediately starts me to think of an EAV-like1 database system, although it is a highly controversial scheme to use in a relational database system like mysql, to use on any system actually...
A few problems that come to mind (most points apply to EAV too btw)
You will lose any logical structure
As any type of data can be linked to any type of entity, so - in your database at least - there is no logical relation between your attributes (or columns in your case) and your entities (tables in your case), other then just being present.
Very, very hard to maintain
If your tables grow, what columns should be indexed? How would you prevent from someone ignorant - and as you say they are by default - adding 200 columns to a table? Numerous other problems can be summed up here...
What about restrictions?
How are you gonna decide who is allowed to add/delete/edit what columns? And how are you force them to choose the right column-type? Or when a table is added: what should be the (coumpound) primary key? Remember: your administrators are ignorant. I guess this would rise the need for meta-tables, holding this kind of information. Are you sure you want to write all the logic for this? And are you sure you are wanting to keep track of bugs etc, bugs which will most probably allow your system to collapse like a card-house?
It smells like an excel sheet...
Without functions that is, but still. So why not send your administrators a link to google docs? ;)
No really, it sounds like a very bad idea...
Please post your full user-case, I'm quite sure we can think of a better solution then adding columns and adding tables to a database.
I'm designing a PHP/MySQL solution for my youth athletic organization that will display schedules and standings for the teams participating in any given season. Unfortunately, I'm just learning the ropes when it comes to database design and having a bit of a challenge wrapping my brain around what should be a relatively simple concept. Perhaps someone can step in and clarify a few points?
What I'm unclear on is how exactly to structure the database(s) and tables to get started correctly. This is what I will ultimately need to set-up:
We have approximately 50 member schools. Each will need their own log-in ID and password. I was thinking about storing these in their own separate database because the accounts will be re-used again each season to represent teams and allow the coaches to log-in and update their game results.
Each season has two different sports. For example, the upcoming fall season has a girls volleyball league and a boys flag football league. Each league then has multiple divisions (divided by geographic region) in which the schools play their regular-season schedule. I'm not sure if each season needs its own separate database, each league, etc.
Each division's regular-season will be imported from a scheduling program (via an Excel spreadsheet) and displayed on its own webpage where schools can view their upcoming games and log-in to update results.
As game results are updated, I'm going to need to find a way to have those results reflected on a separate webpage where that division's league standings are displayed.
For a clearer demonstration of what I'm trying to do, have a look at these two mock pages I created for the schedules and standings data, respectively:
http://www.712jefferson.org/pal/schedules.html
http://www.712jefferson.org/pal/standings.html
This is where I'm looking for your guidance. How exactly should I structure the MySQL framework for all of this data?
I'm thinking a separate database for the school log-in ID's and then a separate database for each seasonal sport (e.g. Boys Volleyball 2013) with separate tables for each division and x-number of columns to represent the schedules and standings therein.
Does that sound about right? Am I thinking about it all wrong? Any assistance or guidance to help flesh out this thought process would be MUCH appreciated!
Thank you so much!
Ouch. You have taken on a big job. Are you absolutely sure that nothing you are going to do cannot be done by something that is already available? Well, if you are sure, read on.
Firstly, the hardest part of what you want to do is managing your user access. I'd advise that you start off by writing your user management module before you go any further.
For what you want, it seems likely that Drupal or one of the other senior CMS systems would be a great way to bootstrap the system. Drupal will handle your user management right out of the box (or with minimal problems) and you could write the rest of your code as static nodes. This also makes it easy to add blogs, forums, news and to manage mailing lists etc.
As stated in the comments above, you do need to keep your data together. it would be good to keep data for historical comparisons too.
If not extending a CMS, after you have got back from the psychiatrist, you will need something along the lines of:
header file to access the db and check for user authentication.
footer file to display your data
individual page files to present or obtain your data.
Database structure for handling the users (at minimum) should be IRO:
Person - details of individual users
username - link person to a username
email - email addresses
club - sports club details
password - passwords
logon - record of logon attempts
role - record of role of individuals in your site
permissions - list of required permissions to access areas of the site
role_permissions - default permissions for each role
person_role - link person to role
person_permissions - link person to permissions (only needed if some individuals need extra permissions not given routinely by their role)
club_person; person_email; - link people to clubs and to their email addresses.
To handle the matches you will need:
team - team name, group and club reference
grouping - list of groups eg by age.
divisions. - list of divisions
venue - list of venues. Include GPS!!!
match - division, grouping, team1, team2, venue, date, time
result - team1 reported result, team 2 reported result, approved result (you may need to intervene!) match.
As you can see you need a fair few tables but YOU MUST NOT try to do the fun stuff with the actual teams UNTIL you have your user access working properly.
What I have sketched out for you is a db in normal form. No textual data is duplicated and the data is easy to retrieve, index and display. I do feel this question is too broad for SO as designing a database for you is a bit out of scope but I do think the general format is useful.
Each table should only contain unique necessary data eg:
Person: personid int, surname, forename, style, whenadded, whoadded, inuse
email: emailid, email, whenadded, whoadded, inuse
email_person: emailpersonid,emailid,personid, whenadded,whoadded,inuse
This allows multiple people to share one email and multiple emails to be applied to one person with no text duplication. IDs should be type INT AUTO_INCREMENT PRIMARY KEY rather than SERIAL as this saves a whole lot of storage space and you'll never fill an INT in this application.
The other tables should be created in the same way. The whoadded and whenadded columns are optional and quite storage hungry but can be very useful. inuse is essential set this to a BOOL and you can remove teams without deleting them - the data is not lost. A whenremoved and whoremoved is useful too for audit.
A word on passwords - please ensure you store these as a SALTED HASH. If you do this, when your site is hacked, no-one will have the password that they also use for their internet banking exposed. People are often idiots. You have to look after them.
As I said, a bit out of scope so I'll end the answer there - it gives you as requested the basic outline of a 4th Normal Form Db that will be robust and extendable but leaves you to do the work. Why not ask more questions if the problem turns out to be too hard.
Good luck.
ADDED:
DIY Framework:
If you don't want to learn to use one of the existing frameworks or CMS, you will need to write your own. Oddly, this is actually very easy.
header.php:
<?PHP
$mysqli=new mysqli(credentials....)//connect to database and present a mysqli or pdo object.
session_start(); //open a session
//you will need to authenticate your session here - see below
?>
footer.php:
<HTML>
<HEAD>
<TITLE>
<?PHP echo $pagetitle;?>
</TITLE>
</HEAD>
<BODY>
<?PHP echo $content;?>
</BODY>
</HTML>
These are used by mypage.php:
<?PHP
require("header.php");
//do some stuff that generates $content
$pagetitle="mypage.php";
require("footer.php:);
?>
It should be stressed that this is the bare minimum you will need and is truly sucky - it is just presented to show how this should be begun, not an exemplar of ideal code. It will work though.
The key is creating a header that presents the variables you will need, such as a db connection, username, user logon status etc. and a footer you can enter details into to present the data. The footer is the only place where you combine HTML and PHP.
Use your $_SESSION to store information that needs to persist between pages.
These files can be as simple or complex as you like - I created my own ages ago that do several checks on the user and session and can display scripts, custom CSS files and such in the footer. It's not hard to do if you start simple and build on as you need. SO will be here to help you.
One word of caution: although you can start very simple, what you are trying to do has legs and will get out of hand. Please audit your code after you have it up and running to make sure that you have not inadvertently included security flaws. It is very easy to include these as you get into a project and need a quick fix and they can be devlishly hard to spot later on unless you are looking for them.
I am in your shoes, and the best solution I found was to use Backend as a Service (Baas) providers such as Parse.com or Stackmob.com or many others. They do complete database hosting for you plus your user management (login/register/forgot_password etc) so you don't have to worry about it. You access them via REST API and they also have PHP libraries on the Github.
Since you are new to database management, which is a non-trivial task, this solution may save you some headache.
Of course, you still have to decide how to organise your tables (or 'classes' in Parse, 'schema' in Stackmob etc) but they also provide help with their relation APIs. They have a pre-defined User table specifically designed for storing users.
Surely their API is not as flexible as SQL but it also safe from SQL injection, a downside of that flexibility. On the other hand, they also offer custom code to enhance that flexibility.
Edit.
Forgot to mention, those BaaS platforms also allow to store arrays as database fields, which can be really handy.
This can be a big build. You may want to try an existing service for league management. There's a few out there. I know a few friends who use Teamopolis and are very happy with the service, and I think it accomplishes everything you're looking for.
To store multi language content, there is lots of content, should they be stored in the database or file? And what is the basic way to approach this, we have page content, reference tables, page title bars, metadata, etc. So will every table have additional columns for each language? So if there are 50 languages (number will keep growing as this is a woldwide social site, so eventual goal is to have as many languages as possible) then 50 extra columns per table? Or is there a better way?
There is a mixture of dynamic system and user content + static content.
Scalability and performance are important. Being developed in PHP and MySQL.
User will be able to change language on any page from the footer. Language can be either session based or preference based. Not sure what is a better route?
If you have a variable, essentially unknown today number of languages, than this definately should NOT be multiple columns in a record. Basically the search key on this table should be something like message id plus language id, or maybe screen id plus message id plus language id. Then you have a separate record for each language for each message.
If you try to cram all the languages into one record, your maintenance will become a nightmare. Every time you add another language to the app, you will have to go through every program to add "else if language=='Tagalog' then text=column62" or whatever. Make it part of the search key and then you're just reading "where messageId='Foobar' and language=current_language", and you pass the current language around. If you have a new language, nothing should have to change except adding the new language to the list of valid language codes some place.
So really the question is:
blah blah blah. Should I keep my data in flat files or a database?
Short answer is whichever you find easier to work with. Depending on how you structure it, the file based approach can be faster than the database approach. OTOH, get it wrong and performance impact will be huge. The database approach enforces more consistent structure from the start. So if you make it up as you go along, then the database approach will probably pay off in the long run.
eventual goal is to have as many languages as possible) then 50 extra columns per table?
No.
If you need to change your database schema (or the file structure) every time you add a new language (or new content) then your schema is wrong. If you don't understand how to model data properly then I'd strongly recommend the database approach for the reasons given.
You should also learn how to normalize your data - even if you ultimately choose to use a non-relational database for keeping the data in.
You may find this useful:
PHP UTF-8 cheatsheet
The article describes how to design the database for multi-lingual website and the php functions to be used.
Definitely start with a well defined model so your design doesn't care whether data comes from a file, db or even memCache or something like that. Probably best to do a single call per page to get an object that contains all the fields for that single page, rather than multiple calls. The you can just reference that single returned object to get each localised field. Behind the scenes you could then code the respository access and test. Personally I'd probably go the DB approach over a file - you don't have to worry about concurrent file access and it's probably easier to deploy changes - again you don't have to worry about files being locked by reads when you're deploying new files - just a db update.
See this link about php ioc, that might help you as that would allow you to abstract from your code what type of respository is used to hold the data. That way if you go one approach and later you want to change it - you won't have to do so much rework.
There's no reason you need to stick with one data source for all "content". There is dynamic content that will be regularly added to or updated, and then there is relatively static content that only rarely gets modified. Then there is peripheral content, like system messages and menu text, vs. primary content—what users are actually here to see. You will rarely need to search or index your peripheral content, whereas you probably do want to be able to run queries on your primary content.
Dynamic content and primary content should be placed in the database in most cases. Static peripheral content can be placed in the database or not. There's no point in putting it in the database if the site is being maintained by a professional web developer who will likely find it more convenient to just edit a .pot or .po file directly using command-line tools.
Search SO for the tags i18n and l10n for more info on implementing internationalization/localization. As for how to design a database schema, that is a subject deserving of its own question. I would search for questions on normalization as suggested by symcbean as well as look up some tutorials on database design.
I'm a hobbyist, and started learning PHP last September solely to build a hobby website that I had always wished and dreamed another more competent person might make.
I enjoy programming, but I have little free time and enjoy a wide range of other interests and activities.
I feel learning PHP alone can probably allow me to create 98% of the desired features for my site, but that last 2% is awfully appealing:
The most powerful tool of the site is an advanced search page that picks through a 1000+ record game scenario database. Users can data-mine to tremendous depths - this advanced page has upwards of 50 different potential variables. It's designed to allow the hardcore user to search on almost any possible combination of data in our database and it works well. Those who aren't interested in wading through the sea of options may use the Basic Search, which is comprised of the most popular parts of the Advanced search.
Because the advanced search is so comprehensive, and because the database is rather small (less than 1,200 potential hits maximum), with each variable you choose to include the likelihood of getting any qualifying results at all drops dramatically.
In my fantasy land where I can wield AJAX as if it were Excalibur, my users would have a realtime Total Results counter in the corner of their screen as they used this page, which would automatically update its query structure and report how many results will be displayed with the addition of each variable. In this way it would be effortless to know just how many variables are enough, and when you've gone and added one that zeroes out the results set.
A somewhat similar implementation, at least visually, would be the Subtotal sidebar when building a new custom computer on IBuyPower.com
For those of you actually still reading this, my question is really rather simple:
Given the time & ability constraints outlined above, would I be able to learn just enough AJAX (or whatever) needed to pull this one feature off without too much trouble? would I be able to more or less drop-in a pre-written code snippet and tweak to fit? or should I consider opening my code up to a trusted & capable individual in the future for this implementation? (assuming I can find one...)
Thank you.
This is a great project for a beginner to tackle.
First I'd say look into using a library like jquery (jquery.com). It will simplify the javascript part of this and the manual is very good.
What you're looking to do can be broken down into a few steps:
The user changes a field on the
advanced search page.
The user's
browser collects all the field
values and sends them back to the
server.
The server performs a
search with the values and returns
the number of results
The user's
browser receives the number of
results and updates the display.
Now for implementation details:
This can be accomplished with javascript events such as onchange and onfocus.
You could collect the field values into a javascript object, serialize the object to json and send it using ajax to a php page on your server.
The server page (in php) will read the json object and use the data to search, then send back the result as markup or text.
You can then display the result directly in the browser.
This may seem like a lot to take in but you can break each step down further and learn about the details bit by bit.
Hard to answer your question without knowing your level of expertise, but check out this short description of AJAX: http://blog.coderlab.us/rasmus-30-second-ajax-tutorial
If this makes some sense then your feature may be within reach "without too much trouble". If it seems impenetrable, then probably not.
The cms I'm currently working with only supports live editing of data (news, events, blogs, files, etc), and I've been asked to build a system that supports drafting (with moderation) + revision history system. The cms i'm using was developed in house so I'll probably have to code it from scratch.
At every save of a item it would create a snapshot of the data into a "timeline". The same would go for drafts. Automated functionality would pull the timeline draft into the originating record when required.
The timeline table would store the data type & primary key, seralised version of the data + created/modified dates + a drafting date (if in the future)
I've had a quick look around at other systems, but I've yet to improve from my current idea.
I'm sure someone has already built a system like this and I would like to improve on my design before I start building. Any good articles/resources would help as well.
Thanks
I think using serialize() to encode each row into a single string, then saving that to a central database may be a solution.
You'd have your 'live' database with relevant tables etc., but when you edit or create something (without clicking publish) it would instead of being saved in your main table go into a table like:
id - PRI INT
date - DATETIME
table - VARCHAR
table_id - INT
type - ENUM('UNPUBLISHED','ARCHIVED','DELETED');
data - TEXT/BLOB
...with the type set to 'unpublished' and the table and table_id stored so it knows where it is from. Clicking publish would then serialize the current tables contents, store it in the above table set to 'archive', then read out the latest change (marked as unpublished) and place this in the database. The same could also apply to deleting rows - place them in and mark as 'deleted' for potential undelete/rollback functionality.
It'll require quite a lot of legwork to get it all working, but should provide full publish/unpublish and rollback facilities. Integrated correctly into custom database functions it may also be possible to do all this transparently (from a SQL point of view).
I have been planning on implementing this as a solution to the same problem you appear to be have, but it's still theoretical from my point of view but I reckon the idea is sound.
This sounds very wiki-like to me. You may want to look at MediaWiki, the system used by Wikipedia, which also uses PHP and MySQL.
DotNetNuke is a good open source CMS, you could read the soure for that system to get ideas. Or you could simply use DotNetNuke.
http://www.dotnetnuke.com/
I think that there are many systems out there that would support this functionality out of the box. Although I don't know al your considerations for doing a custom build, consider looking at some of these. It is very likely that they will be able to support what you need, and then some.
Consider having a look at Drupal, I think still the leading CMS for publishing. Drupal in combination with the workflow module contains all that you need:
http://drupal.org
http://drupal.org/project/workflow
And add save draft for usability:
http://drupal.org/project/save_draft