Skip to main content

    Filter by idea status

    Filter by product

    859 Ideas

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Make Top operator without sort in conditional lookup warn userSUBMITTED

    If I create a Conditional Lookup field, it will by default use the Max operator to enforce only one result from the lookup. If I change the operator to Top without a Sort specified (give me the first record whatever it is, formally non-deterministic) , I get the same code as I would with the None operator.While it seems the result of the None operator code enforces 1 result for the lookup (which is mandated by the SET statement, see: https://learn.microsoft.com/en-us/sql/t-sql/queries/update-transact-sql?view=sql-server-ver16#best-practices). I wonder if you could prove that the undetermined result from the INNER JOIN is the same record as would have been returned by a TOP(1). I suspect that it may not always be the same record.If I specify a Sort, I see that the code implements a Top 1 explicitly. What I would like is that a Top operator without a sort gives a warning on apply / Deploy that offers the user a choice:None operator (because this code will mostly be faster, but not always) explicit Top without Sort. This option will almost always be slower and may or may not return the same result as an INNER JOIN would, but will be explicitly what the user asked for. The option to specify a Sort: this may actually be what the user needed.This choice could be influenced by the operators on other lookups in the table, as bundling them together is faster than running them serially.See some code examples below. I have a list of breweries, which guarantees mutliple breweries for some US states. And I have a list of states with population per age. I am looking up an age from the state table to the brewery table based on the state name being equal. There are at least 87 records for each state ( age 0 - 85 plus 999 for people over 85 years of age). Max operator: Top without sort / None operator: Top with sort: 

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Be able to define a default value for a field without using a transformationSUBMITTED

    It is currently possible to define a default value for a column as a transformation. Due to the (rather strange) choice of using an actual transformation for this, it is impossible to apply this to Simple Mode tables.It is quite common to want a backup value for a field in case a mapping does not fill it. In staging tables you will commonly need to add a transformation with an IsEmpty condition, in MDW tables you need to turn off Simple Mode and add a transformation with a default column value. The latter adds a raw table with associated I/O.A better solution would be to use a named default constraint (see: https://learn.microsoft.com/en-us/sql/relational-databases/tables/specify-default-values-for-columns?view=sql-server-ver16) that uses DDL to ensure a field gets a default value if it is not specified in an insert. Obviously this means dropping the constraint to change data types, but that is minimal overhead compared to the advantage of not needing explicit transformations.Default column constraints can also be applied in bulk operations (see: https://learn.microsoft.com/en-us/sql/relational-databases/import-export/keep-nulls-or-use-default-values-during-bulk-import-sql-server?view=sql-server-ver16) meaning that they can also apply to Custom Data. This is an improvement to the current status quo there:  Default column values make the model more explicit and allow a user to see this information from the database structure instead of needing to dive into code. A default value should be a property of a field, not a transformation. The fact that SQL Server deviates from the ANSI standard does not block the implementation here. Additionally, this allows more use of Simple Mode which should speed up performance. 

    rory.smith
    TimeXtender Xpert
    rory.smithTimeXtender Xpert

    Make instances and data areas more consistentSUBMITTED

    With the new release Data Areas are implicitly implemented as schemas in the backing database. As you can also apply schema behaviours and rules per table, this can become a bit messy (or make users not use these functionaliities). It also makes it unclear what a best practice for implementation would look like.It is understandable to have the features that exist in 20.10.x available to be able to migrate existing projects into the new release. I think it would be better to relegate this functionality to deprecated (i.e. hidden for new implementations). That would make the setup something like:Instance (implicitly a database) Data Area (implicitly a schema) Tables Views .. This allows users to split an instance into separate areas, for instance to have separate staging per source. I would then add an option to push “technical tables” to separate schemas, i.e. _R _I _M _PK etc.Needing to go to table settings and individually assign schemas takes too long to be really useful and should no longer be required in the new release outside of dealing with migrated implementations.Additionally, it would be good to be able to perform data movements between instances as this allows you to create a setup where you have separate instances for staging and a central instance for merging and MDW storage. This allows you to have multiple smaller Hyperscale instances and not be limited by log I/O thereby greatly increasing the throughput and size applicability.