How can I create a table in Oracle with a tree view design. I'm not with coding with any programming language, I want only table design for example
Capital
- share
- Preference Share
Liabilities
- Secured loan
- Unsecured loan
- debenture
Assets
- Fixed Assets
- Tangible Assets
Above all are in one single table.
Here Capital, Assets and Liabilities are the main fields of the table and under those are child nodes.
It's not clear what you mean by tree design. Are you referring to a design pattern known as "generalization specialization"?. By this I mean that an unsecured loan is a subtype of liabilities, and your three main categories could be lumped together into some supertype. Another way to describe this pattern is "inheritance modeling in relational design".
If so, the subject of table design for gen-spec has come up numerous times in SO.
Table design and class hierarchies
Here's one of the best articles, follow the pointers taking you to Martin Fowler's discussion of the object-relational mismatch.
How to do Inheritance Modeling in Relational Databases?
Related
When employees log in through
site.com/employees/login
They get to access the vendor_companies table through
App\Models\Employee\VendorCompany Model
When vendors log in through
site.com/vendors/login
They get to access the vendor_companies table through
App\Models\Vendor\VendorCompany
Is this approach ok?
Although having a single model is most common, what you have is fine. There are times when you want to do customization in one model depending on how you want to treat Vendors. Two different models allow you to have a cleaner separation and makes it easier to maintain functionality, especially between two teams - one team that builds vendor features vs. other team that builds features for employees.
When you build your controllers, you will have to put additional effort to identify whether you are dealing with vendor or employee and then call the appropriate model.
On the flip side, it is common to have a single model and you have customization based on vendor or employee. Give your method a shot and try your methodology.
Was it Taylor Otwell himself or some company or someone else?
I am just curious and wanted to know. There is nothing to it in first page of google search so I posted the question here.
Maybe this will be down voted immediately. In that case I will delete it.
In software engineering, the active record pattern is an architectural pattern found in software that stores in-memory object data in relational databases. It was named by Martin Fowler in his 2003 book Patterns of Enterprise Application Architecture.1 The interface of an object conforming to this pattern would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table.
The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated, the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.
This pattern is commonly used by object persistence tools and in object-relational mapping (ORM). Typically, foreign key relationships will be exposed as an object instance of the appropriate type via a property.
Resource: Laravel Up And Running book from Matt Stauffer
then you can find it even here.
So Taylor only used this pattern to implement in Laravel framework even though many they consider that as a weak part of Laravel.
I am wondering how the models in code ignitor are suposed to be used.
Lets say I have a couple of tables in menu items database, and I want to query information for each table in different controllers. Do I make different model classes for each of the tables and layout the functions within them?
Thanks!
Models should contain all the functionality for retrieving and inserting data into your database. A controller will load a model:
$this->load->model('model_name');
The controller then fetches any data needed by the view through the abstract functions defined in your model.
It would be best to create a different model for each table although its is not essential.
You should read up about the MVC design pattern, it is used by codeigniter and many other frameworks because it is efficient and allows code reuse. More info about models can be found in the Codeigniter docs:
http://codeigniter.com/user_guide/general/models.html
CodeIgniter is flexible, and leaves this decision up to you. The user's guide does not say one way or the other how you should organize your code.
That said, to keep your code clean and easy to maintain I would recommend an approach where you try to limit each model to dealing with an individual table, or at least a single database entity. You certainly want to avoid having a single model to handle all of your database tables.
For my taste, CodeIgniter is too flexible here - I'd rather call it vague. A CI "model" has no spec, no interface, it can be things as different as:
An entity domain object, where each instance represents basically a record of a table. Sometimes it's an "anemic" domain object, each property maps directly to a DB column, little behaviour and little or no understanding of objects relationships and "graphs" (say, foreign keys in the DB are just integer ids in PHP). Or it can also be a "rich (or true) domain object", with all the business intelligence, and also knows about relations: say instead of $person->getAccountId() (returns int) we have $person->getAccount(); perhaps also knows how to persist itself (and perhaps also the full graph or related object - perhaps some notion of "dirtiness").
A service object, related to objects persistence and/or general DB querying: be a DataMapper, a DAO, etc. In this case we have typically one single instance (singleton) of the object (little or no state), typically one per DB table or per domain class.
When you read, in CI docs or forums, about , say, the Person model you can never know what kind of patter we are dealing with. Worse: frequently it's a ungly mix of those fundamentally different patterns.
This informality/vagueness is not specific to CI, rather to PHP frameworks, in my experience.
I'm talking about HUGE forms - like medical forms with 1000+ fields.
How do you logically create models for them? Do you include every single little field as seperate model? Do you have the whole form as a HUGE model with every single field? Do you have formsections as models and each formsection has few fields?
I know this might be subjective, but I really want some advice on someone who has dealt with this before and save others a lot of time down the road by avoiding mistakes at the onset.
Your data model should follow an EAV method. Medical systems are well suited to this approach as not all patients are going to have all this information filled in. This method allows you to fill in what is appropriate and populate your model. Makes organizing the data easier as well.
As for organizing it in the view, I suggest you break it up into sections where sections are logically related to each other (past history, family history or by type of information), making the information easier to digest.
In MVC, 1 model 1 tables or 1 model several tables?
I am building an application that contain 3 tables. I don't know whether I should create one model for all 3 tables or create 3 models for 3 tables.
In the case I use 3 models for 3 tables, where should I put the code if I want to join these 3 tables? Put the code in any one of 3 models?
Any suggestions?
In general, the 'Model' part of MVC should be interpreted as a 'Presentation Model' or 'View Model' - that is, a class that encapsulates all the data and behavior needed by the View. This may or may not be equivalent to the Domain Model.
Domain Models should be designed to be independent of UI. This means that such Models should not be polluted with UI-specific data and behavior - such as determining whether a particular button is enabled or not.
You may also want to show the same Domain Objects in several different views (e.g. Master/Detail, or Display/Edit), and if those views differ sufficiently, having a View Model for each View will be beneficial.
So, in general, you should design your Domain Layer and your Presentation Layer independently.
In the Domain Layer, you can choose to model your three tables as three classes. Books like Fowler's Patterns of Enterprise Application Architecture and Evans's Domain-Driven Design contains lots of guidance on how to model relational data as Domain Models.
When it comes to modeling the views in MVC, it makes most sense to create one Model per View. Such a View Model might simply encapsulate a single Domain Object, but it may also encapsulate and aggregate several different Domain Objects.
In this way, you can ensure separation of concerns, and that your classes follow the Single Responsibility Principle.
For very simple scenarios, it may make sense to collapse the Domain Model and the Presentation Model into one layer, but you should realize that this essentially means that there's no Domain Model in the solution - all models would be pure Presentation Models.
Usually you will create one model per table, so in your case it means you need 3 models.
When i say "Model" i mean a class that will represent a single row (usually) in a single table.
for example:
Tables:
Products
Orders
Customers
in such case the most easy and simple is to create 3 different classes (which represents the data model of the application) where the first class represents a single product the next represents an order and the last class will represent a single customer.