Database

Depends on what you are trying to do.

Is this an actual report you are generating or are you just doing an export of the data? It you're doing an export, you can only export 50K rows.

Actually I just gave the overview of my project. My exact question is after 5-6 years the data will be larger in the view so fetching particular data is time taking, then what should I use instead of view to get the data faster.

Sorry, but your "overview" misses the most important numbers:

- Number of rows in both tables as of now

- Number of rows added per year in both tables

Then some questions:

- How often do you run that report?

- Does a user need to wait or is this generated in the background?

- Did you consider synced records?

- Did you already implement database optimisation? Indexing, foreign keys etc...

It is Travel booking application first table have Booking (Table 1) details done by the user and second table have Travel package (Table 2) added by the application admin.

- Number of rows in both tables as of now :  now Table 1 have 200 rows and Table 2 have 150 rows.

- Number of rows added per year in both tables : Consider Table 1 have 1000 rows and Table 2 have 200 rows.

- How often do you run that report? : One is running monthly and other daily, and user can also generate report on his demand by providing date and time from interface, and based on user input it check the data in view and gives the result.

- Does a user need to wait or is this generated in the background? : For generating the report I'm providing a link and startProcess inside interface, as the user clicks on click the process gets started.

- Did you consider synced records? : Yes  

- Did you already implement database optimisation? Indexing, foreign keys etc... : I'm using record types in application so implemented relationship between record types. Table 1 has foreign key of Table 2 primary key.

Inside view I'm using Inner join and comparing the foreign key of Table 1 and primary key of Table 2.

That's not a whole lot of data even after 6 years.

You never answered my question - is this just a straight data export or are you doing some number crunching and generating some kind of report in Excel?

That's not a whole lot of data even after 6 years.

You never answered my question - is this just a straight data export or are you doing some number crunching and generating some kind of report in Excel?

It is straight data export based on some filters used in smart service.

With that small data volume, do not invest any time. Your design is good enough.

But with the time the data will get larger so need the solution for it.

What do you mean? For what problem? You do not have any! At least not in the next 20 years.

The reason is that my manager is asking me to use something else rather than using views.

Thank you so much.

If you use the plugin "Export Data Store Entity to Excel" I do not see any other option. It does not work with Appian synced records.

Somewhat overkill but if you *absolutely* want to avoid views, there is the option of doing a materialized view. Some DBMSes offer this option where the view can refresh itself (Oracle, SQL Server). Otherwise, you'd have to have a scheduled process that runs SQL or Stored Procs to refresh the data in the table periodically.

More info here: