I am creating an Entity Relation Diagram for my database.
I would like to know if it's possible to make a dense table, I would like to compact all my rectangle in the table.
On the following picture, you have an example of a table of my diagram. I would like to reduce the margin between all lines to create a dense table.
Yes, make sure you select the whole row before resizing the row. There's currently no resize feature for a selected cell, which in other cases does not seem technically correct.
I found the solution, it was really simple:
Click on a rectangle.
Click on right, on the tab "Arrange" and change the Height Size.
Related
I am looking to create an attendance sheet but not getting the magic idea for the same. Possible options for me
Use grid but done know how to pass date values as grid column headings
Use table but don’t know how to edit the same. grid is editable component.
Please help me with the thought process
I don't think that Ext.grid.Panel is the component for this purpose. Grid conceptually more resembles database tables (fixed columns/fields repeated many times in rows/records) than spreadsheets (cells w/o prescribed purpose).
Also, grid has a lot of features like sorting, column re-ordering, column hiding that you would need to turn off for this purpose. Grid is just an overkill.
I would probably go with a custom table-like form with checkboxes. The form would be dynamically generated as employees can change and dates as well.
I want to design a database to store crossword puzzles,
mainly I have 2 tables:
Questions Table, Grid Table,
Questions Table(q_id, question , answer...)
Grids Table (g_id, name, ....)
when I come to relate Questions Table with Grids Table, I am thinking of a good way,
Questions_Grid(q_id, g_id), the pair would be a primary key,
another solution that my boss suggested : Grids Table ( g_id, q_ids, ....)
q_ids store all the ids of the question used in this grid
which one is better? and if you have better options ?
It looks like your boss's suggestion is to store a list of question ids as a text column in the grid table. If I understand what you're asking and that's really it, the first one is much better, of course, because it's normalized. In your scheme, you can make many useful queries that would be messy or impossible (and slow, if possible) in your boss's scheme.
The first option is better, in that way the schema of your database does not restrict the number of questions per grid. A rule of thumb is that when you have to change the schema to make the application scale you haven't got an optimal schema.
a link table with one tuple pair is more normalized.
Question_grid
-------------
q_id
g_id
this will allow you to have as many questions as necessary for the grid, and no more.
if you try to hardcode the list, then each grid will need the same number of questions, or will have blanks or something.. no good.
Well the rule is to make a linking table when you have a "one"(grid) on "many"(questions) relationship. So your option would be the best answer, its normalized!
Has anyone figured out a good way to make a hidden table/matrix column take no horizontal space?
I could use some crazy conditionals to dynamically determine the contents of the columns (effectively sliding them leftward as far as possible), but that is nasty, plus doesn't allow for varying column widths in the columns to the right of the one I want to hide.
The idea is that when a parameter is set to "Any" then the column with the corresponding value should display. But when the parameter is set to an explicit single value the report doesn't need to contain that column any more (it will be separately listed as a condition at the top of the report).
This lets me use the same report in different situations, some requiring hiding unnecessary columns.
P.S. I think Microsoft should add expressions for object sizes, and I think they should add CanShrinkHorizontally to the CanShrink(Vertically) that already exists...
I think you are looking at the Hidden property of the column. Something that is hidden will still take up space. What you want to change is the Visibility of the column. Right click on the column header and click Column Visibility and set it there.
It looks like you can hide groups, and groups can be rows or columns.
Click the down-arrow next to "Column Groups" at the bottom of the Design pane, and turn on Advanced Mode. Modify the Hidden property of the Static group representing the desired column. Poof! You've made the entire column take up no space.
I struggled with this and came up with a workaround/solution.
In my scenario it was critical to have the RowGroups EffectiveDate, Description AND TransactionID. I wanted to hide the TransactionID column, because it was part of the grouping I couldn't set the Columns Visibility.
Before
After
So what I did was Merge Cells for the Description/TransactionID Header (and called it Transaction Type) and also for the first row of the tablix "Opening Balance".
Set the TransactionID textbox Hidden: True
The trick was to make the [DESCRIPTION] Right BorderStyle: None
Then set the Cell under [TRANSACTIONID] Top BorderStyle: Solid and Top BorderWidth 0.5
Alternatively make the fore color of the column you want to hide white and set border styles appropriately.
I'm creating a database with Access. This is just a test database, similar to my requirements, so I can get my skills up before creating one for work. I've created a database for a fictional school as this is a good playground and rich data (many students have many subjects have many teachers, etc).
Question 1
What is the difference, if any, between using a Lookup column and a many-to-many associate table?
Example: I have Tables 'Teacher' and 'Subject'. Many teachers have many subjects. I can, and have, created a table 'Teacher_Subject' and run queries with this.
I have then created a lookup column in teachers table with data from subjects. The lookup column seems to take the place of the teacher_subject table. (though the data on relationships is obviously duplicated between lookup table and teacher_subject and may vary). Which one is the 'better' option? Is there a snag with using lookup tables?
(I realize that this is a very 'general' question. Links to other resources and answers saying 'that depends...' are appreciated)
Question 2
What attracts me to lookup tables is the following: When creating a form for entering subjects for teachers, with lookup I can simply create checkboxes and click a subject for a teacher 'on' or 'off'. Each click on/off creates/removes a record in the lookup column (which replaces teacher_subject).
If I use a form from a query from teacher subject with teacher as main form and subject as subform I run into this problem: In the subform I can either select each subject that teacher has in a bombo box, i.e. click, scroll down, select, go to next row, click, scroll down, etc. (takes too long) OR I can create a list box listing all available subjects in each row but allowing me to select only one. (takes up too much space). Is it possible to have a click on/off list box for teacher_subject, creating/removing a record there with each click?
Note - I know zero SQL or VB. If the correct answer is "you need to know SQL for this" then that's cool. I just need to know.
Thanks!
Lookup columns in tables will cause you more stress than joy. Unless you need them for Sharepoint, they should be avoided. You may wish to read http://r937.com/relational.html and http://www.mvps.org/access/tencommandments.htm
I wouldn't use them. Your example is fine, but there are limitations. What do you do when you need to reference another field from the Subject table other than the name? How would you differentiate subjects that are only offered on a semester basis?
You have no way of getting a count of how many subjects each teacher is assigned without some ugly coding.
Another limitation, is when you start identifying who taught what courses during a given school year.
I'm kind of unclear on your second question, but it sounds to me like you need a subform with a dropdown list.
If you want to do the checkbox thing, it quickly becomes a lot more complicated. To me, you're starting from user interface and working backwards to structure, instead of going the other direction.
I hesitate to mention it, but in terms of full disclosure you should know that in A2007 and A2010, you have multi-value fields available, and they are presented with exactly the UI you describe. But they have many of the same problems as lookup fields, and are quite complex to work with in code. Behind the scenes, they are implemented with a standard many-to-many join table, but it's all hidden from you.
I wish MS would make the listbox with checkbox control that is used with MV fields available for all listboxes, but binding that to a many-to-many join table would be complex if the listbox control were not designed for that (with link child/link master properties, for instance).
I tried to come up with a way to offer you the UI feature you prefer from multi-value fields without actually using multi-value fields. That seems challenging to me.
The closest I could come up with is to load a disconnected recordset with your "List" choices and a check box field. Then create a form, or subform, based on that recordset which you present in datasheet view. It could look similar to a combo bound to a multi-value field. In the after update event of the checkbox field, you would need code to add or remove a record from the junction table as required.
However, I don't know if this is something you would care to tackle. Earlier you indicated a willingness to learn SQL if needed; the approach I'm suggesting would also require VBA. Maybe take a look at Danny Lesandrini's article, Create In-Memory ADO Recordsets, to see whether it is something you could use.
OTOH, maybe the most appropriate answer for you is to keep the multi-value fields and get on with the rest of your life. I'm stuck. But now that we know you are actually using multi-value fields, perhaps someone else will be able to offer you a more appropriate suggestion.
I'm hoping to display a multi-valued column in a tabular UI format. By multi-valued column, I mean a column in which a single cell can simultaneously have multiple values -- aka a list of values. These values might be drawn from a short list of possibilities (e.g. an enumeration) or from a long list (e.g. another table). Imagine a table of contacts with a "friends" column that can refer to zero or more other contacts.
I need the ability to add new values, remove values, and ideally the values would be listed horizontally and word wrapped. I have a feeling that no out-of-the-box datagrid control on the planet can do this, but I figured this is the right forum to ask such a question.
I'm guessing that the current state of the art is to display the information in a form, not in a table (e.g. "details" of a row). However, we would like to actually display the values in a column of the table in a horizontally wrapped, in-line editable fashion. At this time, we are planning to use WPF, so I'm hoping for a WPF solution.
WPF is definitely the right tool for this job. I don't think you'll find it very difficult to get the layout you want once you understand a few core WPF concepts (mostly binding and DataTemplates). I would suggest maybe a ListView/GridView with a GridViewColumn with a custom CellTemplate containing an ItemsControl with its own DataTemplate...Simple, really ;-)