I am learning MVC and SQL and I am trying to make an application that takes daily user data which is put in a day table. The day is linked to a week table and the weeks are linked to a year tables. I have entities for all 3. I am having problems with linking and orgainising them though. When I try link them it always uses their Primary Keys and so I am getting duplicate errors.
For example, when I have it that the user inputs the primary key value, and try to make Week 1 in, say 2015, but there is already a Week 1 in 2014, I get an error because they both have the same ID.
But when I have the computer automatically do the primary keys (so it goes 1, 2, 3, ...), I am only able get the days linked to the primary key. E.g. I have WeekID (the Primary Key) and WeekNo in the model. I have week 1 and 2 made and filled out, then go to make week 3 but accidentally make WeekNo 4, it's WeekID would still be 3 as it is the third week made. I delete it and make a new one and put in 3 as the WeekNo, then the WeekID is 4. This is a problem because then when I make a day, and click the dropdown menu for picking the week it goes in, I get the options "1, 2, 4" rather than "1, 2, 3" because it is using the primary keys. Even if the user never makes a mistake and has to delete it, this is still a problem when the next year comes around and the week numbers repeat.
My question is, does any one know how I could go about making it so that there are no duplicate problems and that they can be linked by something other than the primary key? Basically, when the user makes a week, they can select what year it goes into out of available years from the create page of Week. And the same when making a day, that they can select which week it goes in by number. Has any one encountered this kind of problem and gotten past it?
You are inventing calendar actually.
I would rather have one column with type of TIMESTAMP. And on the server side/ or via SQL queries calculate day/week/year number (you didnt mention which RBDM you use). That will prevent you from having relation issues and also will help you in manipulating TIMEZONES in the future.
Here is the post for JAVA sample where week number is calculated
Otherwise you will need to use composite primary keys for:
day - (DAY_ID, WEEK_ID, YEAR_ID)
week - (WEEK_ID, YEAR_ID)
year - (YEAR_ID)
Related
I'm a pretty new programmer and I'm working on a project that I'm not sure how to make work. I'm hoping for some advice please.
Part of the project I'm working on will be used by a company to allow employees to sign up for lunch from their computers. I'm doing the project in MVC ASP.NET
The interface will look something like this:
----------------------
|1200 | Employee Dropdown Name 1
| Employee Dropdown Name 2
|---------------------
|1230 | Employee Dropdown Name 1
| Employee Dropdown Name 2
|---------------------
and on and on and on.
With this company, everything has to be recorded and stored. So, I already have a table with employee information. That will populate the drop down areas. Lunch times need to be stored in the database so it can be searched years down the line. So it has to be in a table.
The table get more tricky because not every time of the day is available for lunch (i.e. - no lunches after 0430 and before 0800).
My question is about how to create the future time slots in the database.
I could obviously make the table with all of these rows already in places for several years down the line. That's time-consuming, though, and I'll have to go back in in several years and fix it. Horrible idea.
What I'd LOVE to do is make it so every 24 hours, the database just automatically adds new rows with the next days times available - so just increment (at midnight, the program will just add the next day's times associated with that date (so at midnight on February 6, 2020, it will create February 7, 2020 0000, February 7, 2020 0030, etc. I've studied a lot but I'm still beside myself on how to make this work.
Thanks in advance everyone!!!
As I understand, you want to drive your interface from the database table so that the user can select Name 1 and Name 2 and a time slot and submit.
It sounds like you also want the available timeslots to be driven by the database also (ie, timeslot in table without names with it is availlable). This is not a good idea. As you mentioned, you would be inserting data that is not actually a record but a placeholder. That will be very confusing down the track when you come to query the data.
My approach would be to do the following:
* add NOT NULL constraints to all columns in your database (if your database supports this feature) or have your app complain very much about NULLS in any of the columns. There is no need for NULLS in your use case by the look of it.
the database should have a CHECK constraint that the time is within the allowable time range, and (assuming employees can not double book time slots) a CHECK constraint that there is no overlapping time slots, and also a UNIQUE constraint that ensures no duplicate times.... adjust to suit your needs.
your app populates times between 0800 and 1630 (8AM and 4:30PM) and also query the database for all records matching the current day so those booked slots can be removed from the list of available time slots... adjust to suit.
your app sends the user request of name and time slot to the DB. All the critical requirements are accepted or rejected by the DB schema and if there is something wrong, display an appropriate error in the app.
This way, your database is literally storing records of booked lunches.
I would NOT go down the path of pre inserting as then it becomes more complex as some records are "real" and some are artificially generated records to drive a GUI...
If you can't do the time slot calculations in your app rather than in the DB, then at least use a separate table that is maintained by a worker thread in your app OR if your DB supports it, a Stored Procedure which returns a table of available time slots.
I would use the stored procedure if I was avoiding doing complex time calculations in my app (also avoids need to worry about time zones - if you make sure to only store and display UTC times in your DB).
Having in mind structure like this:
LunchTimeSlots (id, time_slot)
Employee (id, name, preferred_time_slot_id, etc)
Lunches(employee_id, time_slot_id, date)
You need a scheduled job to add records to the "Lunches" table every midnight. How to define the job depends on your database vendor. But most of the popular rdbms have this feature. (f.e. mssql)
Despite it's possible to do what you want with db schedulers or any other scheduler, i would recommend to avoid such db design. It's always better to write real facts to the database like a list of employees or fact that lunch was served
to employee at 1pm today.
Unlike real facts, virtual data can be always generated "on-the-fly" by sql queries. F.e. by joining employees to list of dates from today till year 2100, we can get planned lunches for all employees for next 80 years.
I'm creating a database that will be used for a web app for editing and preview of a Monthly Work Schedule. The principle behind this is to make a highly flexible layout that will provide building blocks for filtering, preview, and the making of templates.
The way it works:
There are 10 tables - each has a pretty simple data structure (ID, ShortName, Descr).
I want to make a table that will exclusively use data that already exists in those tables and save those combinations as new schedules.
So, you pre-make all the elements and then you put them together like Legos for final product/schedule.
Important - I want to enforce 7 tables- Center, Rank, Role, One, Two, Year, Month. Without all those selected (or if duplicate) you can't save/create a new schedule.
Now, I have two dilemmas here:
1. Should I create clustered indexes from those values like in the image
2. Should I make PK - and make it like serial number so that it's incremented using the data from those tables, e.g. Center(01) + Rank(02) + Role(12) + One(15) + Two(01) + Year(2019) + Month (07) = 0102121501201907
Also, another dilemma is Year/Month entry
I need JUST Year and JUST Month as Columns and values. Which way would be recommended here?
Can I make a Custom Data Type that will trim month and day from date to have just Year?
Should I define Year as int and make a defined table with Months (ID, Name)?
I can't go with a date because I need Year and Month as individual constraining parameters. I don't need Days - and removing day value from a date format through functions and user interface sounds like too much work for something that should be relatively simple. (performance-wise)
Also, making Year and Month as int and defining 12 Months - I'm afraid I'll lose some functionality just because I'm not familiar enough to use it.
This is my first work of this kind, and I feel like these decisions will heavily influence everything I do onward, so any advice whether from experience or from theory/book/site is highly appreciated.
So I'm developing a database for an agency that manages many relief staff.
Relief workers set their availability for each day in one of three categories (day, evening, night).
We also need to be able to set some part-time relief workers as busy on weekly, biweekly, and in one instance, on a 9-week rotation. Since we're already developing recurring patterns of availability here, we might as well also give the relief workers the option of setting recurring availability days.
We also need to be able to query the database, and determine if an employee is available for a given day.
But here's the gotcha - we need to be able to use change data capture. So I'm not sure if calculating availability is the best option.
My SQL prototype table looks like this:
TABLE Availability Day
employee_id_fk | workday (DATETIME) | day | eve | night (all booleans)| worksite_code_fk (can be null)
I'm really struggling how to wrap my head around recurring events. I could create say, a years worth, of availability days following a pattern in 'x' day cycle. But how far ahead of time do we store information? I can see running into problems when we reach the end of the data set.
I was thinking of storing say, 6 months of information, then adding a server side task that runs monthly to keep the tables updated with 6 months of data, but my intuition is telling me this is a bad fix.
For absolutely flexibility in the future and keeping data from bloating my first thought would be something like
Calendar Dimension Table - Make it for like 100 years or Whatever you Want make it include day of week information etc.
Time Dimension Table - Hour, Minutes, every 15 what ever but only for 24 hour period
Shifts Table - 1 record per shift e.g. Day, Evening, and Night
Specific Availability Table - Relationship to Calendar & Time with Start & Stops recommend 1 record per day so even if they choose a range of 7 days split that to 1 record perday and 1 record per shift.
Recurring Availability Table - for day of week (1-7),Month,WeekOfYear, whatever you can think of. But again I am thinking 1 record per value so if they are available Mondays and Tuesday's that would be 2 rows. and if multiple shifts then it would be multiple rows.
Now and here is the perhaps the weird part, I would put a Available Column on the Specific and Recurring Availability Tables, maybe make it a tiny int and store something like 0 not available, 1 available, 2 maybe available, 3 available with notice.
If you want to take into account Availability with Notice you could add columns for that too such as x # of days. If you want full flexibility maybe that becomes a related table too.
The queries would be complex but you could use a stored procedure or a table valued function to handle it fairly routinely.
I'm developing a c# application that consists of Document Incoming System for my police station.
In this system, variable document's contents are been saved to an SQL database. I must give them a "Document Number".
I'm achieving all of these, but i want that every years last day such as 31.12.2014, the numbers that have been given to a document like "2145" will turn to "1" at the the first day of year 01.01.2015.
So, the records must be 2014/2145. and the last days of years turns to 2015/1.
How can I achieve this?
You count the existing documents for the same year, then add one.
So if you want to store a document that belongs to 2013, you first count how many existing documents you have in 2013, then add one.
I can't write the sql for you, because you haven't described the data structure, but it should be simple enough using SQL COUNT, and DATEPART to retrieve only the year from a date field.
I'm trying to figure the best approach to solve this problem.
--
I have a "History" table that,
lists ALL years that have data.
If a user clicks a given Year, it segues to a new Table and,
lists ALL months that have data.
Clicking a given month, shows a new table that,
lists ALL days that have data.
Clicking a specific day, shows a list of one or multiple Time Stamps.
--
What is the best approach to solve this?
If user creates a Time Stamp. I need to insert it with today's date.
I also need to have the ability that if a user,
Deletes a given year. Everything in that year is deleted.
That same way,
Deleting a month, deletes everything in that month, for it's particular year.
And so on, to the point where the user should be able to delete Individual Time Stamps.
--
I thought I would Use a Dictionary with key for the "year". 2012, 2013, ...
And each retrieving another Dictionary with key for the "month", 1, 2, 3, 4, ...
And so on ... and so on ...
I also thought I could make a model using Core Data.
A Class Year representing the "Year" entity, having a relation to many possible Months, and each month, having a relation to many possible days, and days to Time *Stamps*.
And last,
I thought of creating a model with only two Entities.
Entries, with only one attribute "Date", that has a to-many relationship to "Time Stamps", receiving All the possible Time Stamps for that given day.
I am new to iOS programming. So this is all theory for me. But I did follow some Core Data tutorials and others working with NSDictionaries, protocols delegates and so on.
The "Dig In" approach as I go trough, seems more elegant. Specially because I think I could delete a particular given object in a cascade manner?
Do any of these make sense? Or is there a more obvious easy way to go about it? Also, please consider in the answer what would be easier to implement if a user chooses to delete a given entry in the "tree"
Any help is most appreciated.
Thank you advance!
Nuno
If you are going to rely on Core Data or any database engine, the best way to solve this is to use the database itself.
I see two possible solutions (there is more of course). The first, the simplest :
Entity
- timestamp
- year
- month
- day
- all_the_stuff_you_need
Make year, month and day readonly, updated along timestamp. Indexes: year, year+month, year+month+day. Easy call.
That way, you can very simple query the database, asking it to return the entities you need and only the entities you need.
A more complex setup would be:
Entity
- timestamp
- all_the_stuff_you_need
- year -> Year
- month -> Month
- day -> Day
Year
- year
- entities ->> Entity
Month
- month
- entities ->> Entity
Day
- day
- entities ->> Entity
So basically, 3 data domains for the years, months and days, months and days being immutable.
That structure is more complex, but it gives a better view of your data. You have a direct access to more information on your data as the data domains are explicit and well defined.
A third solution would be to create a date entity with year, month and day, with one entry per day. A middle ground between the two solutions above. Less interesting I think, but hey, it may suit your needs anyway.