Code to auto-update tables on set date

Question

Code to auto-update tables on set date

Viewing 5 posts - 31 through 34 (of 34 total)

You must be logged in to reply to this topic. Login to reply

Sergiy SSC Guru Points: 110206 More actions · Answer 1

From those tables I cannot figure out - how can a user participate in more than 1 team? Is it considered an impossible situation?

is there any connection between users and students?

in Messages - Name, Phone, Email - are they of some users registered in the system? If so, why not just reference those contact details by simple UserId?

_____________
Code for TallyGenerator

thetubageek SSC Veteran Points: 204 More actions · Answer 2

From those tables I cannot figure out - how can a user participate in more than 1 team? Is it considered an impossible situation?

Users are people who are logging into the website to view information. Nothing more.

Is there any connection between users and students?

At this point, no. Not to say that won't change in the future, but that is not a concern at this time.

In Messages - Name, Phone, Email - are they of some users registered in the system? If so, why not just reference those contact details by simple UserId?

The Development Team simply want a table to hold information that is input on the form. Apparently, the next class is going to work on future processes involving this form and table.

Yes, I realize this is lame. Unfortunately, I don't have much say in what happens. I've already vented my frustrations in how the classes operate. Hopefully, they will take my suggestions and implement them.

Sergiy SSC Guru Points: 110206 More actions · Answer 3

thetubageek wrote:

From those tables I cannot figure out - how can a user participate in more than 1 team? Is it considered an impossible situation?
Users are people who are logging into the website to view information. Nothing more.
Is there any connection between users and students?
At this point, no. Not to say that won't change in the future, but that is not a concern at this time.

You said - it. Users are people.

Students? Most likely, they are people too. At least most of them.

So, you must have a table "Person".

Student and User tables contain PersonID plus relations and attributes which make that person a student or a user.

thetubageek wrote:
In Messages - Name, Phone, Email - are they of some users registered in the system? If so, why not just reference those contact details by simple UserId?

The Development Team simply want a table to hold information that is input on the form. Apparently, the next class is going to work on future processes involving this form and table.

Yes, I realize this is lame. Unfortunately, I don't have much say in what happens. I've already vented my frustrations in how the classes operate. Hopefully, they will take my suggestions and implement them.

It was pretty obvious that those tables are used as a simple data dump for web forms.

Yep. it's lame. That's pretty much what everyone said to you on the 1st page of this thread. And what you've been so frustrated about.

Now it seems you understood where your frustration should have been directed. 🙂

But the problem is - "lame" is almost a synonym of "agile".

Marathon is not made of sprints. If you run sprint after sprint you can never complete a long distance.

Unless you eliminated all stayers and compete with the same sprinters as yourself.

So, if you want to stay on that "Agile" boat stop being frustrated and accept the lower standards for data handling.

And don't get flamed when someone calls your solutions "dumb". Because yes, they dumb, but what did you expect?

There is no time for much of a thinking when you're running a sprint.

_____________
Code for TallyGenerator

thetubageek SSC Veteran Points: 204 More actions · Answer 4

You said - it. Users are people.
Students? Most likely, they are people too. At least most of them.
So, you must have a table "Person".
Student and User tables contain PersonID plus relations and attributes which make that person a student or a user.

I'll send an email to the Development Lead and the instructor for his class and see if that is an option we can take advantage of.

Yep. it's lame. That's pretty much what everyone said to you on the 1st page of this thread. And what you've been so frustrated about.
Now it seems you understood where your frustration should have been directed.
But the problem is - "lame" is almost a synonym of "agile".
Marathon is not made of sprints. If you run sprint after sprint you can never complete a long distance.
Unless you eliminated all stayers and compete with the same sprinters as yourself.
So, if you want to stay on that "Agile" boat stop being frustrated and accept the lower standards for data handling.
And don't get flamed when someone calls your solutions "dumb". Because yes, they dumb, but what did you expect?
There is no time for much of a thinking when you're running a sprint.

My frustration was more in the scope that my team and the Development teams were on different mindsets. It didn't help that they waited until about 2/3 of the way through the class to have a session discussing Agile. It also doesn't help that I recently completed my Master's degree in a program with a focus on database management and administration and even then, I was under the impression that designing and configuring a database was more a marathon than a sprint. In my head, I envisioned having the database set up in such a way that even if the front-end development was incomplete, it would be entirely feasible to improve the font end without having to completely "reinvent the wheel" when it came to the design of the database structure. Now, with what my team is having to essentially acquiesce to, there will inevitably be at least one (if not several) redesigns of the database along with attempts to make the existing data work within the scope of those redesigns.

This was why I had suggested restructuring of the courses they are currently offering. Currently, we meet M/W/Th/Sat, with occasional meetings of all the classes together at certain times.

Below is an approximation of what I sent them, but I'll likely send this updated recommendation after I post this reply:

Week 0: Instructors form teams based on final enrollment numbers and have the teams assigned to the available projects.
Week 1: Introduction week/Intro to Project Management. All students in all classes will meet together during this time. Projects are introduced to the students and all teams associated with said projects are introduced to each other. Classes meet M/W/Th. Saturdays are used as Team Meeting sessions to collaborate on the projects and give status updates.
Week 2: Cover Documentation (BRD, Database Design Document, Project Plan, etc.). Team Meeting will be spent getting an early start on these documents.
Week 3: Cover Agile. Teams continue work on documentation
Weeks 4: Begin working on class-specific coursework. Documents are due on Saturday of this week so project work can begin the following week.
Weeks 5-13: Continue class-specific coursework. During this time, Team Meetings are spent working on the project as a full group during odd weeks, and status reviews with all instructors and project stakeholders are done on even weeks.
Weeks 14-15: Testing and bug fixes performed M/W/Th. Status review meetings on Saturdays.
Week 16: Testing and bug fixes performed M/W/Th. Final presentations given on Saturday.

I would like to take the opportunity to apologize for my earlier outburst, as I now believe some of my frustrations with the class were being redirected onto all of you because I didn't feel like I was getting the answers I needed due to the rushed timeline of the project. I agree that if things had been handled differently, we could have possibly got some of these things done or at least had an approximate idea of how to have them documented for future projects to take on.

ScottPletcher SSC Guru Points: 100949 More actions · Answer 5

It's terribly scary to me that this is a "class". They're teaching people exactly the wrong things to do.

In my head, I envisioned having the database set up in such a way that even if the front-end development was incomplete, it would be entirely feasible to improve the font end without having to completely "reinvent the wheel" when it came to the design of the database structure.

That indeed is the whole point of the logical design and normalization process: to insure that the final physical db design is flexible and strong enough to accommodate changes later, and without having to do rewrites of code (since code hasn't been created yet while doing modeling).

Striving for a "simple" design is a terrible idea. The data should drive the design, not some short-sighted hope to keep things "simple".

You will end up with too many columns in tables, too many columns where they don't belong (since there's no proper table to hold them) and all the subsequent well-known update anomalies caused by that situation.

But, if you can move on from this and never have to deal with it again, I guess it's ok from your standpoint.

SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.