I am new the sharepoint development, hope my question makes sense,
using sharepoint 2010,
structure of the application I am working on is like below:
site collection root
some lists and content types that are common to all sites below.
a site for doing something with x-type projects
a site for doing something with y-type projects
a site for doing other stuff not directly related to the projects but may be indirectly
if I was designing a tratidional database application, I would have a BaseProject entity, and would discriminate the sub projects by a projectType field or even would have subEntities which are related 1-1 (kind of inheritace relationship) to the baseProject entity-if normalization issues bother me much.
people around suggest to have seperate lists for x,y projects which have different workflows, document templates, different users, etc, and isolate the contents of different sites, aggerate the datas when reporting, not even to think of inheritance-like relations between entities but this means the relations from common entities would need to be made seperately to the different lists of projects. and many look-up lists would be repeated around different lists of "project" entities. so expanding the data model would be difficult in the future. and for the reports that are interested in whole scope of the application, would need to aggregate the lists scattered among the sites.
if I design the lists to be more expandable later on
only one baseProject list in root site with a projectType column:
I would have to filter every lists that contains more than what I need in a specific site
one baseProject list in root site and sub-lists for other types of
projects in sub sites: I would need to syncronize the data between base list and sub lists. to have all the project items in baseProject list.
the question is: what are the best practices to design sharepoint lists to model inheritance between entities ?
regards..
It is very difficult to answer specifically without a lot more detail on the project. Building your site model is a complex task that is specific to a particualar projects requirements.
In simple terms, if a list has different processing associated with it, then it is a separate list. If you need to indicate similar data, then use defined fields, which will maintain your consistency. Reporting can be made to work whatever your structure, so treat that as a lesser issue.
But the primary focus for site design should be the functional behaviour of the business. If you match that correctly, then everything else will eventually fall into place.
Related
I'm working on a Vue app with Vuex state management using Type Script. I'm wondering where I should place my model classes. Currently I have them under "store" in a sub-directory "models". Now I have many more custom types used by the models and I'm not sure anymore whether the "store" directory is the right place. But on the other hand, the models are in a tight relationship with the state, right?
What is best-practice for this?
Short answer: put the "models" folder next to your "store" folder, not inside.
Long answer:
There are generally two strategies for organizing files:
Grouping by utility (eg. models, services, components etc.)
Grouping by domain category (eg. users, products, bookings etc.)
Whatever you choose there's a tradeoff.
The first strategy is most common. It prevents your project from getting many folders in your root folder, and it makes it easy to decide where to put new files. The drawback is that closely related files end up far apart, and as your codebase grows you will spend time looking for files that depend on each other.
The second keeps related files nicely together. Imagine for example a folder called Pets that contains a pet model, a pet component, a pet service and a unit test for that service. That makes navigating through Pet logic a lot easier. However, directories follow a tree structure while the domain model looks more like a graph and that can cause difficulties for properly organizing your files.
I find that people most often organize code by utility first, and by domain category second, but I'm not sure if I would call it best practice. The other way around has often worked out nicely for me as well.
If you organize by utility then you should avoid nesting them because it's almost never the case that one kind of utility uniquely belongs to another. Certainly models don't uniquely belong to a store. A component that depends on a model is just as tightly coupled to that model as a store. Therefore placing the "models" folder next to the "store" folder would make more sense.
I have an MS Access database with several tables. Almost all tables contain inventory information about different classes of items (there are some utility tables which store extra information, such as a list of classes and lists of commonly used lookup values). Some classes of items have particular data specific to them - for instance, volume is relevant for liquids but not solid objects, but all objects have a location. The logical structure of my database is a textbook example of a case where an object oriented model provides clarity and maintainability benefits:
There is one basic table which is a catch-all table for all items that don't fit into other categories. It contains a few columns, like item name, date, location and notes that is applicable to any item. This would be the top superclass, e.g. class InventoryTable.
There are tables for specific classes, such as a table for printer cartridges. This table will have all the columns that InventoryTable has, but also include some specialized information that is only relevant for printer cartridges, such as printer model, ink color and brand. This table would be a subclass, e.g. class PrinterCartridgeTable : InventoryTable.
Sometimes there is a deeper inheritance structure. For example, there may be a table for all documents (class DocumentTable : InventoryTable, includes extra field for how many pages a document has) and then another table for letters (class LetterTable : DocumentTable which also has columns for sender and recipient of the letter). The assumption is that one would look for letters in the LetterTable, and if not found there, could try looking in the DocumentTable and the top level InventoryTable.
Let's say my dates are currently displayed as MM/DD/YYYY. I want to change them to ISO format (YYYY-MM-DD). Currently, I have to open every single table I have (about 20) and change the format in each one of them one by one. If there was some kind of inheritance mechanism, I could instead change the format only in my top-level InventoryTable, and all my other tables would inherit the change.
Or, suppose I decide to store a new piece of data, called "Owner", for all items. This would describe who entered the item into the inventory. I could simply add this column to InventoryTable, and it would appear in all the child tables automatically.
Lastly, let's say I make cosmetic changes such as rearranging the order of columns. Let's say in my document-related tables, the page number appeared at the end. I instead move the page number to the very beginning of the table - this would propagate to both DocumentTable as well as LetterTable but not unrelated tables.
Bear in mind that I am editing these tables manually using the GUI of MS Access 2013. When editing information pertaining to a single class of items, I would not like to switch back and forth between tables or queries to edit different parts of the same record - I want to be able to see and edit all of the information for any given record in one place. Therefore, some complicated solutions based on chaining queries may be impractical.
Is it possible for me to accomplish what I want (the inheritance structure) in Access using some kind of object oriented scheme? Is there an alternative way of obtaining the same benefits? Do I have no choice except to give up and manually propagate every change to all tables?
The relational data model does not have inheritance built in. There are several design patterns that allow the database designer to mimic the behavior of inheritance in a system of relational tables. Two common designs are known as "Single Table Inheritance" and "Class Table Inheritance". There are two tags in this area with questions that relate to these two techniques, and a brief description in the info under the tag. With one of these two techniques, you will be able to model a superclass/subclass situation.
For a more complete description, you could search for Martin Fowler's treatment of the two techniques on the web. There is a third technique, called "Shared Primary Key" which allows you to enforce the one-to-one nature of the IS-A relationship between members of the subclasses and members of the superclass.
Your big problem in MS Access is going to be implementing the code that these techniques leave to the application programmer. Get ready to do plenty of coding in VBA, and tying this code to the user's dashboard.
It is not possible to make tables in Access object-oriented because it is not possible to directly associate methods with tables. An object is defined to be both properties and methods. Access is not designed to do that.
Also note that Access is not the best that Microsoft has to offer. You will get more power and capabilities with SQL Server.
I am working on redesigning a database for a product called Project Billing. I am having trouble coming up with table names. In the old database, the names were super obscure (PRB_PROJ_LVL), so old is of no help. The database is small - 10 tables or so - but will grow over time.
Here's the problem - Projects are an entity (and table), but the word is also used as an adjetive. Example
Project - a table containing projects.
ProjectTask - a table containing project tasks; this is a child of Projects.
ProjectTemplate - a table for project templates, which is not a child of Projects. Project templates just serve as a model for creating a bunch of ProjectTasks.
So, how do I show that ProjectTask is a child of Project but ProjectTemplate isn't? Thanks as always.
Internal documentation of your schema and its intended use is one of the better ways to do this. Relying on naming convention alone will always leave open the possibility for interpretation - explicit definitions don't do that. That said, we have defined some objects which are intended for use as models (templates in your case). These model objects are not to be used or directly manipulated by the production application and over time are mutable with new objects being based on modified models. One way we tried to apply self-descriptiveness was the introduction of schema. Since we had different departments that could make use of the same model objects, we had something along the lines of (adjusted to apply to your question without assuming too much):
[dept_X].[projects]
[dept_X].[project_tasks]
And for templates, which are never directly used by the application or users (per say):
[model].[projects]
[model].[project_tasks]
As a programming reference for our developers, schema definition scripts contain documentation describing object relationships (as do the objects internally do via foreign keys, etc). As an added measure, a wiki article is generated for all new objects sorted by project. Objects existing prior to this new system (my onboarding) get documented as they get modified or as time permits which ever comes first.
I have read in MSDN that in Sharepoint 2010 developer can realize many-to-many relationships betwen lists using intermidiate list and sme custom logic.
Could you recomend me some already created controls for this porpose?
What exactly do you want controls to do? As the article states, the method is simply to have two lists, and a third with a lookup to each of those two lists. You create items normally in those two lists and then create another item to link pairs of existing items. You can either do all of this manually using OOB controls, or you can make a custom page (or pages) that will be used to create both an item and to link it as well. Note that in sharepoint you also have the option of using multi-valued lookups. This will perform slower, and have less options when querying the data, but it does make entering the data using OOB webparts easier.
All that said, we can't really help you much without knowing what you're looking for.
I newbie in Sharepoint development.
I has some hierarchical structure like internet forum:
Forum
Post
Comment
For each of this entities I create content type.
I see, that Sharepoint allow store in list different content types and I can store all forums with their posts and comments in single list (Forum and Post will be 'Folder', Comment - Item).
From other side, I can create separate lists for each content type:
Forums List, Posts List, Comments List and link them in some way.
Is anybody can outline Pros and Cons for both solutions? I have about 2 weeks experience in Sharepoint and can't select best way.
P.S. Sorry for my English.
The short answer is: it depends.
First, they need to logically fit together. A user should expect items of these various types to be grouped together (or at least wouldn't be surprised that they have been grouped together). And in terms of design, they should have some common intersection of list type and fields. Combining Documents, Discussions, and Events into a single list wouldn't be a good idea. Likewise, I'm not sure Posts and Comments (as you mention above) would be a good fit for a single list. They just don't logically fit and their schemas probably do not have enough in common.
Once that has been determined, I would put multiple Content Types in the same list if they are meant to be used together. Will you want to show all of these items, regardless of Content Type, together in a view? Do all of these items share the same workflows, policies, permissions, etc? If the answer is no for any of these, then split the Content Types into different lists.
As I said, it depends. I'm not sure there really is a hard or fast rule for this. I see it a little like database normalization. We know the forms and the options. But depending on the project, sometimes we normalize a little more, sometimes we denormalize a little more, but we almost never (I hope) have one, monster table that contains every type of row in the database.