https://schemafreesql.com SchemafreeSQLSchemafreeSQL FREE TRIAL No Sign-Up Required Sign In [ ] menu * Sign In * ----------------------------------------------------------------- * Sign Up * FAQ * Docs * Pricing * Demo Apps [github-mar] * Support/Feedback * Blog * * Examples + Create/Update/Set/Append Objects + Payload Parameters + Create and Query Nested Attribute Structures + Object References + Customer Order with Object References + Modify Complex Attributes + Modify Arrays + GOT Graph + Bulk Import Data, Fluid as Code With SFSQL you code your application and the structure of the data follows. Enjoy the flexibility of NoSQL's schemaless capabilities while maintaining the Deep Querying Power of SQL Relations with SFSQL - a "Join-free" SQL-like Language. All within a relational database of your choice (currently MySQL 8 only ). Example Use Cases SFSQL is best suited for use cases with relatively modest writes, complex and/or dynamic structures, which benefit from ad-hoc queries. - Dashboard/Admin databases - Product databases with varying product attributes - Sparse data structures - Complex tree and graph structures - Application backends with uncertain schema requirements Launch Cloud SFSQL No Sign-Up Required On-Premise available upon request Cloud SFSQL Infrastructure Providers Fly.io - Aiven.io - AWS Aurora Serverless 2 - Planetscale - Google Cloud - Microsoft Azure - Digital Ocean - AWS - UpCloud Click Here To See Our Hello World "Shop Admin" App Made from this single request payload [app-payloa] Demo Apps [github-mar] [ ]"Shop Admin" Demos * Cloudflare Worker * Deno Deploy * Netlify (AWS Lamda Function) * Google Cloud Functions * Azure Functions * PHP (SFSQL Cloud DB Hosted on AWS Aurora Serverless 2 - SFSQL API VM Hosted on Fly.io) [ ]"Todo App" Demos * Cloudflare Worker * Deno Deploy * Netlify AWS Lamda Function * Google Cloud Functions * Azure Functions * PHP (more complex allows for "DAG" TODO structure) (SFSQL Cloud DB Hosted on AWS Aurora Serverless 2 - SFSQL API VM Hosted on Fly.io) [ ]"GOT" Most Connected Demos * Netlify AWS Lamda Function [github-mar] * PHP * GOT Demo Attribute Structure (SFSQL Cloud DB Hosted on Planetscale - SFSQL API VM Hosted on Fly.io) [ ]Object Store Explorer of Demo Apps * PHP Object Store Explorer (SFSQL Cloud DB Hosted on AWS Aurora Serverless 2 - SFSQL API VM Hosted on Fly.io) [ ]Basic Blogging System * PHP Blog and Admin (SFSQL Cloud DB Hosted on AWS Aurora Serverless 2 - SFSQL API VM Hosted on Fly.io) Here is a Non-Trivial Data Problem SFSQL Solves with Ease (*) The Problem ( ) The Solution ( ) Insert Data ( ) Query Data add Dog Toy Dog Toy add CPU CPU CPU CPU increment Likes reset Explanation JSON Request Payload JSON Response Payload List Products List Brands Search reset Explanation JSON Request Payload JSON Response Payload Storing, Querying and Modifying Disparate Data Structures is difficult to do efficiently. Example problem: We want to store products with vastly different attribute sets from one another into the same product database. We want users to be able to query across all available product attributes (e.g. CPU's CPU by speed, Dog Toys Dog Toy by breed size). We will continually be adding new products and types, each with a combination of common attributes (e.g. price) and uncommon attributes (e.g. flavor). We want to efficiently 'reference' certain attributes (e.g. 'Brand') as Objects, because otherwise we'd have duplicate 'Brand' attributes (e.g. Brand 'Support Address', 'Phone', etc.) embedded in-line with their parent attributes across our data store. We want to efficiently 'reference' products as objects in order to include them within queries that reference them (e.g. sales reports by various product attributes) And of course we want queries to run at indexed speeds regardless of what product attributes are searched on. Did we mention that we want all of this as pain free as possible? We considered using: [ ] A SQL DB and determined that we'd need to: * Create a table per product type * Create indexes for each product table * Determine which product attributes from each different product table would need to be queried on. * Create and manage the indexes on each different product table. * Need to use a UNION to pull together query results that span multiple product types / multiple tables. * Repeat the above steps every time we added a new product type that introduced new attributes. * Create a 'brand' table * Need to use JOINs within each product query that included 'brand' info * Need to JOIN the product table to whatever main table we are querying if we want product info included. [ ] A SQL DB with a JSON Column Type and like a straight SQL DB, found we would still need to: * Create a 'brand' table * Use JOINs within each product query that included 'brand' info * Need to JOIN the product table to whatever main table we are querying if we want product info included. Nicely, the JSON column allowed us to * Consolidate our product table mix down to a single product table that contained only the common product attributes. * Store all the sparse/disparate product attributes within a JSON column on the same, single product table * Add new products containing completely new attributes without database changes Unfortunately, in order to effciently query the product attributes found in the JSON column, we still needed to: * Determine which product attributes from each different product type would need to be queried on. * Create and manage the indexes for the different product attributes sourced from the JSON column. * Repeat the above steps every time we added a new product type that introduced new attributes. [ ] A Document Store like Mongo and determined that we'd need to: * Create a 'brand' collection * Use lookups within each product query that included 'brand' info Nicely, the document store allowed us to * Store all our product attributes whether common or sparse/ disparate in a single product collection. * Add new products containing completely new attributes without database changes. * Performed very fast queries against all our product attributes whether common or sparse/disparate. Unfortunately, we encountered inefficiencies when querying across collections: * When querying the Product collection while using a lookup to the Brands collection, queries slowed down (indexes or not). * The above slowdown also applies to queries run against other collections (e.g. sales records) which need to join/filter to the Products collection. * We realized that eventually we may want most 'object sections' found in the Products collection to be stored into their own separate collections just as we un-embedded Brands. Especially any 'unbounded' object arrays (e.g. many 'user reviews' on each Product). This brought us to the best-practice suggestions that normalizing all objects out from their source documents and into their own collections is generally an anti-pattern in a document store. Document stores shine brightest when the objects being embedded are limited in array size and don't need to be updated separately from their parent documents (very often). All fell short. SchemafreeSQL provides a solution that meets all the needs of example problem. Click on the "Insert Data" and "Query Data" Tabs to see how SFSQL solves this problem efficiently and effectively. WHY SchemafreeSQL ? "With every new project, why do I have to go through so much repetitive upfront work just to store data?" "I am tired of designing tables, altering tables, creating indexes, testing index coverage, optimizing indexes, installing a sdk, managing collections, making sure not to query across collections, having to know my query patterns upfront, learning a new query language, having to change the way I think about data, understanding a best practice that's 5 pages long, and running into a "gotcha" around every corner" "I like SQL and want something that resembles and has the power of SQL and its aggregate functions." "I want an easy way to get data in and out of a database." "I'm a programmer and understand about Objects, Attributes, and Arrays and I want to store Objects, Attributes and Arrays. But I don't want my Object Class structures tightly coupled with my data structures (don't want an ORM). I just want to store and edit Object Instance data." SchemafreeSQL allows easy Modeling, Querying, and Importing of Complex Semi-Structured Data. Object Structures are Created instantly from Unmodified JSON and modified easily with Semi-modified JSON. * Flexibility of "NoSQL" Enjoy the flexibility of NoSQL's schemaless capabilities yet maintain the Deep Querying Power of SQL Relations with SFSQL - a "Join-free" SQL-like Language.. * Keep SQL Functions Use SQL built-in functions within SFSQL queries. (currently MySQL) * HTTP API Access SchemafreeSQL from any language through a ubiquitous JSON-over-HTTP API. Objects References * Every Object is uniquely identified with an oid (Object ID) * Any existing Object can be "referenced" to exist as an attribute under any other Object * No Data duplication (e.g. directly reference an 'item' object from within multiple order lineitems) * Multiple references to the same Object are indistinguishable from each other In the example below, we combine a 'modify' and 2 'query' commands within the same payload. Within the modify, we first create a customer and a couple of items and then reference those within a newly created order using #ref. (*) Store & Query ( ) Results [ { "modify": { "data": { "o:twtest": { "o:customer": { "s:id": "c1111", "s:last_name": "Smith", "o:address": { "s:state": "NY" } }, "o:item": [ { "s:id": "i000", "s:name": "prod 0" }, { "s:id": "i111", "s:name": "prod 1" } ], "o:order": { "s:order_id": "1", "o:customer": { "#ref": "SELECT $o:twtest.customer.oid() WHERE $s:twtest.customer.id='c1111'" }, "o:lineitem": [ { "o:item": { "# ref": "SELECT $o:twtest.item.oid() WHERE $s:twtest.item.id='i000'" }, "i:qty": 12 }, { "o:item": { "#ref": "SELECT $o:twtest.item.oid() WHERE $s:twtest.item.id='i111'" }, "i:qty": 3 } ], "n:total": 99.99 } } }, "_comment": ": modify: create a new order and set customer and items and reference pre-existing customer and items" } }, { "query": { "sfsql": "SELECT $s:twtest.order.customer.address.state as state, TRUNCATE(SUM($n:twtest.order.total),2) as orders_for_state GROUP BY state", "_comment" : "order totals by state" } } , { "query": { "sfsql": "SELECT $s:twtest.order.lineitem.item.id as id, $s:twtest.order.lineitem.item.name as name, TRUNCATE(SUM ($i:twtest.order.lineitem.qty),2) as orders_for_state GROUP BY id,name", "_comment" : "totals by item" } } ] [ { "result.oid" : "97", "_comment" : ": modify: create a new order and set customer and items and reference pre-existing customer and items", "success" : 1, "cmdname" : "modify", "result.anid" : "32" }, { "data" : [ { "orders_for_state" : 99.99, "state" : "NY" } ], "_comment" : "order totals by state", "success" : 1, "cmdname" : "query" }, { "data" : [ { "orders_for_state" : 12, "name" : "prod 0", "id" : "i000" }, { "orders_for_state" : 3, "name" : "prod 1", "id" : "i111" } ], "_comment" : "totals by item", "success" : 1, "cmdname" : "query" } ] A Schemaless Object Store? * Object Structures Created from Unmodified JSON * Store Sparse Data Efficiently * Dynamically Modify Object Structures * No Tables to Create * Auto Index Creation * Join-less Queries In this example Schemaless "Contact" Objects are created, modified, and queried. (*) Store ( ) Query ( ) Results [ { "modify": { "data": { "ContactList": { "Contact": [ { "fname": "John", "lname": "Smith", "age": 29 }, { "fname": "Sue", "lname": "Smith", "age": 27, "MI": "P", "d:birthdate": "02/15/1994" } ] } }, "_comment": "Create Contacts with different Attributes" } }, { "modify": { "data": { "ContactList": { "Contact": { "#update": { "where": "$s:Contact.fname='John'" }, "MI": "D", "d:birthdate": "01/ 15/1992", "Address": { "street": "123 Washington Street", "city": "Boston", "state": "MA", "zip": "02111" } } } }, "_comment": "Modify Object Structure" } } ] [ { "query": { "sfsql": "SELECT $s:.Contact.fname, $s:.Contact.lname, $i:.Contact.age, $d:.Contact.birthdate,$$s:.Contact.Address.street", "_comment": "Query Contacts, Indexes auto created" } } ] [ { "data": [ { "s:Contact.lname": "Smith", "i:Contact.age": 29, "d:Contact.birthdate": "1992-01-15 00:00:00", "s:Contact.Address.street": "123 Washington Street", "s:Contact.fname": "John" }, { "s:Contact.lname": "Smith", "i:Contact.age": 27, "d:Contact.birthdate": "1994-02-15 00:00:00", "s:Contact.Address.street": null, "s:Contact.fname": "Sue" } ], "_comment": "Query Contacts, Indexes auto created", "success": 1, "cmdname": "query" } ] Handle Complex Data Instantly store and query complex data. No tables or indexes to create. Example of the deep hierarchically data that SchemafreeSQL can store and query. (source: clinicaltrials.gov) (*) Store ( ) Query ( ) Results [ { "modify": { "data": { "FullStudy": { "Rank": 699, "Study": { "ProtocolSection": { "IdentificationModule": { "NCTId": "NCT04970017", "OrgStudyIdInfo": { "OrgStudyId": "17200538" }, "Organization": { "OrgFullName": "Assiut University", "OrgClass": "OTHER" }, "BriefTitle": "Correlation Between Left Ventricular Global Strain Measured by Speckle Tracking Echocardiography and Scar Burden Measured by Cardiac Magnetic Resonance Imaging in Patients With Ischemic Heart Disease", "OfficialTitle": "Correlation Between Left Ventricular Global Strain Measured by Speckle Tracking Echocardiography and Scar Burden Measured by Cardiac Magnetic Resonance Imaging in Patients With Ischemic Heart Disease" }, "StatusModule": { "StatusVerifiedDate": "February 2021", "OverallStatus": "Recruiting", "ExpandedAccessInfo": { "HasExpandedAccess": "No" }, "StartDateStruct": { "StartDate": "January 1, 2021", "StartDateType": "Actual" }, "PrimaryCompletionDateStruct": { "PrimaryCompletionDate": "January 2022", "PrimaryCompletionDateType": "Anticipated" }, "CompletionDateStruct": { "CompletionDate": "January 2022", "CompletionDateType": "Anticipated" }, "StudyFirstSubmitDate": "July 16, 2021", "StudyFirstSubmitQCDate": "July 16, 2021", "StudyFirstPostDateStruct": { "StudyFirstPostDate": "July 21, 2021", "StudyFirstPostDateType": "Actual" }, "LastUpdateSubmitDate": "July 16, 2021", "LastUpdatePostDateStruct": { "LastUpdatePostDate": "July 21, 2021", "LastUpdatePostDateType": "Actual" } }, "SponsorCollaboratorsModule": { "ResponsibleParty": { "ResponsiblePartyType": "Principal Investigator", "ResponsiblePartyInvestigatorFullName": "Mohamed Mahmoud Mohamed Abdellatif", "ResponsiblePartyInvestigatorTitle": "Dr", "ResponsiblePartyInvestigatorAffiliation": "Assiut University" }, "LeadSponsor": { "LeadSponsorName": "Assiut University", "LeadSponsorClass": "OTHER" } }, "OversightModule": { "IsFDARegulatedDrug": "No", "IsFDARegulatedDevice": "No" }, "DescriptionModule": { "BriefSummary": "To verify whether GLS and LV mechanical dispersion, measured by two-dimensional speckle-tracking echocardiography (2D-STE) correlate with LV scar burden measured by cardiac MRI in patients with ischemic heart disease.", "DetailedDescription": "Evaluation of presence, localization, and extent of left ventricular(LV) scar tissue in patients with ischaemic heart disease (IHD) is of fundamental importance in clinical practice. It affects the decision making regarding revascularization and is a determinant of subsequent mortality. (Mele, Fiorencis et al. 2016) Late gadolinium contrast-enhanced cardiac magnetic resonance (LGE-CMR) is considered the current gold standard technique for assessment of the scar burden in IHD patients. However, it is not readily accessible in many areas due to availability and cost issues. (Abou, Prihadi et al. 2020), (Bendary, Afifi et al. 2019) Several recent studies suggested 2-D speckle tracking strain as a potential surrogate for cardiovascular magnetic resonance (CMR) late gadolinium enhancement (LGE) imaging. This would be useful in cases where CMR is not available, gadolinium contrast is contraindicated, or in patients at greater risk of adverse long term events. (Erley, Genovese et al. 2019) Among echocardiography derived strain measurements, global longitudinal strain (GLS) was shown to be superior to global circumferential strain (GCS) in its ability to detect subtle myocardial abnormalities due to better reproducibility (Erley et al, 2019). Left ventricular mechanical dispersion (LVMD) is also considered a valuable parameter that was associated with outcomes after myocardial infarction. (Abou, Prihadi et al. 2020).\n\nDespite the growing number of strain related studies in the literature, it is not clear whether the relationship of strain measurements with LGE is strong enough for strain to be considered as a surrogate. (Erley, Genovese et al. 2019). Also, the differences between GLS and LV MD among strain components in this context are not well established." }, "ConditionsModule": { "ConditionList": { "Condition": [ "Ischemic Heart Disease" ] } }, "DesignModule": { "StudyType": "Observational", "PatientRegistry": "No", "DesignInfo": { "DesignObservationalModelList": { "DesignObservationalModel": [ "Case-Only" ] }, "DesignTimePerspectiveList": { "DesignTimePerspective": [ "Cross-Sectional" ] } }, "EnrollmentInfo": { "EnrollmentCount": "51", "EnrollmentType": "Anticipated" } }, "ArmsInterventionsModule": { "InterventionList": { "Intervention": [ { "InterventionType": "Radiation", "InterventionName": "Cardiac MRI, Echocardiography", "InterventionDescription": "Magnetic resonance imaging, Echocardiography" } ] } }, "OutcomesModule": { "PrimaryOutcomeList": { "PrimaryOutcome": [ { "PrimaryOutcomeMeasure": "Scare burden by echocardiography", "PrimaryOutcomeDescription": "To test the correlation between the scar burden measured by cardiac MRI and GLS measured by 2D STE", "PrimaryOutcomeTimeFrame": "One year" } ] }, "SecondaryOutcomeList": { "SecondaryOutcome": [ { "SecondaryOutcomeMeasure": "Value of spickle tracking echocardiography in clinical practice", "SecondaryOutcomeDescription": "Predicting the scar burden in ICMP patients by GLS and mechanical dispersion.", "SecondaryOutcomeTimeFrame": "One year" } ] } }, "EligibilityModule": { "EligibilityCriteria": "Inclusion Criteria:\n\n* Patients presenting for viability assessment in to cardiac MRI unit, Assiut university heart hospital, with a history of previous stemi, at least 3 months after the acute event ( scar stabilization) and up to one year\n\nExclusion Criteria:\n\nPatients with:\n\nContraindication to cardiac MRI (claustrophobia, Patients with eGFR below 30 mL/min/1.73 m2. and patients with metallic implants)\nNon-ischemic cardiomyopathy.\nValvular heart disease (VHD).", "Gender": "All", "StdAgeList": { "StdAge": [ "Child", "Adult", "Older Adult" ] }, "StudyPopulation": "Patients presenting for viability assessment in to cardiac MRI unit, Assiut university heart hospital, with a history of previous stemi, at least 3 months after the acute event ( scar stabilization) and up to one year", "SamplingMethod": "Non-Probability Sample" }, "ContactsLocationsModule": { "CentralContactList": { "CentralContact": [ { "CentralContactName": "Mohamed Abdellatif, MSC", "CentralContactRole": "Contact", "CentralContactPhone": "+201001073747", "CentralContactEMail": "mohamed.abdellatief@med.au.edu.eg" }, { "CentralContactName": "Shimaa Sayed Khidr, PHD", "CentralContactRole": "Contact", "CentralContactPhone": "+201001346551", "CentralContactEMail": "S.khidr@aun.edu.eg" } ] }, "OverallOfficialList": { "OverallOfficial": [ { "OverallOfficialName": "Mohamed Abdellatif", "OverallOfficialAffiliation": "Assiut University", "OverallOfficialRole": "Principal Investigator" } ] }, "LocationList": { "Location": [ { "LocationFacility": "Assiut university", "LocationStatus": "Recruiting", "LocationCity": "Assiut", "LocationZip": "71511", "LocationCountry": "Egypt", "LocationContactList": { "LocationContact": [ { "LocationContactName": "Mohamed Abdellatif", "LocationContactRole": "Contact", "LocationContactPhone": "00201001073747", "LocationContactEMail": "Mohamed.abdellatief@med.au.edu.eg" } ] } } ] } } }, "DerivedSection": { "MiscInfoModule": { "VersionHolder": "July 27, 2021" }, "ConditionBrowseModule": { "ConditionMeshList": { "ConditionMesh": [ { "ConditionMeshId": "D000006331", "ConditionMeshTerm": "Heart Diseases" }, { "ConditionMeshId": "D000017202", "ConditionMeshTerm": "Myocardial Ischemia" }, { "ConditionMeshId": "D000003324", "ConditionMeshTerm": "Coronary Artery Disease" }, { "ConditionMeshId": "D000007511", "ConditionMeshTerm": "Ischemia" } ] }, "ConditionAncestorList": { "ConditionAncestor": [ { "ConditionAncestorId": "D000010335", "ConditionAncestorTerm": "Pathologic Processes" }, { "ConditionAncestorId": "D000002318", "ConditionAncestorTerm": "Cardiovascular Diseases" }, { "ConditionAncestorId": "D000014652", "ConditionAncestorTerm": "Vascular Diseases" }, { "ConditionAncestorId": "D000003327", "ConditionAncestorTerm": "Coronary Disease" }, { "ConditionAncestorId": "D000001161", "ConditionAncestorTerm": "Arteriosclerosis" }, { "ConditionAncestorId": "D000001157", "ConditionAncestorTerm": "Arterial Occlusive Diseases" } ] }, "ConditionBrowseLeafList": { "ConditionBrowseLeaf": [ { "ConditionBrowseLeafId": "M9126", "ConditionBrowseLeafName": "Ischemia", "ConditionBrowseLeafAsFound": "Ischemic", "ConditionBrowseLeafRelevance": "high" }, { "ConditionBrowseLeafId": "M8002", "ConditionBrowseLeafName": "Heart Diseases", "ConditionBrowseLeafAsFound": "Heart Disease", "ConditionBrowseLeafRelevance": "high" }, { "ConditionBrowseLeafId": "M18089", "ConditionBrowseLeafName": "Myocardial Ischemia", "ConditionBrowseLeafAsFound": "Ischemic Heart Disease", "ConditionBrowseLeafRelevance": "high" }, { "ConditionBrowseLeafId": "M5129", "ConditionBrowseLeafName": "Coronary Artery Disease", "ConditionBrowseLeafAsFound": "Ischemic Heart Disease", "ConditionBrowseLeafRelevance": "high" }, { "ConditionBrowseLeafId": "M4743", "ConditionBrowseLeafName": "Cicatrix", "ConditionBrowseLeafRelevance": "low" }, { "ConditionBrowseLeafId": "M5132", "ConditionBrowseLeafName": "Coronary Disease", "ConditionBrowseLeafRelevance": "low" }, { "ConditionBrowseLeafId": "M15983", "ConditionBrowseLeafName": "Vascular Diseases", "ConditionBrowseLeafRelevance": "low" }, { "ConditionBrowseLeafId": "M3050", "ConditionBrowseLeafName": "Arteriosclerosis", "ConditionBrowseLeafRelevance": "low" }, { "ConditionBrowseLeafId": "M3046", "ConditionBrowseLeafName": "Arterial Occlusive Diseases", "ConditionBrowseLeafRelevance": "low" } ] }, "ConditionBrowseBranchList": { "ConditionBrowseBranch": [ { "ConditionBrowseBranchAbbrev": "BC23", "ConditionBrowseBranchName": "Symptoms and General Pathology" }, { "ConditionBrowseBranchAbbrev": "All", "ConditionBrowseBranchName": "All Conditions" }, { "ConditionBrowseBranchAbbrev": "BC14", "ConditionBrowseBranchName": "Heart and Blood Diseases" } ] } } } } } } } } ] [ { "query": { "sfsql": "SELECT $s:.BriefTitle LIMIT 10", "_comment": "BriefTitle query" } }, { "query": { "sfsql": "SELECT DISTINCT $s:.LeadSponsor.LeadSponsorName AS 'LeadSponsorName', $s:.LeadSponsor.LeadSponsorClass AS 'LeadSponsorClass' WHERE $s:.LeadSponsor.LeadSponsorName.vci() LIKE 'University%' ORDER BY LeadSponsorClass,LeadSponsorName LIMIT 10", "data-style": "nvp", "data-format": "json", "_comment": "LeadSponsor query" } }, { "query": { "sfsql": "SELECT $i:.FullStudy.Rank as 'Rank', $s:.FullStudy.Study.ProtocolSection.IdentificationModule.NCTId as 'NCTId' LIMIT 10", "data-format": "csv", "data-style": "colnames", "_comment": "Rank query" } }, { "query": { "sfsql": "SELECT $s:.FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionType as 'InterventionType', COUNT ($s:.FullStudy.Study.ProtocolSection.IdentificationModule.NCTId) as 'cnt' GROUP BY InterventionType ORDER BY cnt DESC", "data-format": "json", "data-style": "dataonly", "_comment": "Count by InterventionTypes" } }, { "showattrs": { "rootattr":"FullStudy" }, "_comment": "show complete clinical trials attribute structure." } ] [ { "data": [ { "s:BriefTitle": "Comparative Effectiveness Analysis of Granulocyte Colony Stimulating Factor Originator Products Versus Biosimilars" }, { "s:BriefTitle": "The Influence of Simple, Low-Cost Chemistry Intervention Videos: A Randomized Trial of Children's Preferences for Sugar-Sweetened Beverages" }, { "s:BriefTitle": "Access Anti-HCV Assay European Union (EU) Clinical Trial Protocol" }, { "s:BriefTitle": "ACCESS HIV ANTIGEN/ANTIBODY COMBO ASSAY EUROPEAN UNION (EU) CLINICAL TRIAL PROTOCOL" }, { "s:BriefTitle": "1-month DAPT Plus 5-month Ticagrelor Monotherapy Versus 12-month DAPT in Patients With Drug-coated Balloon" }, { "s:BriefTitle": "Safety Study of 89Zr-NY001 PET Imaging in Patients" }, { "s:BriefTitle": "Alveolar Ridge Augmentation With Curcumin Combined With Xenograft" }, { "s:BriefTitle": "Safety, Tolerability, and Pharmacokinetics of a Single Intravenous Infusion of XTMAB-16 in Healthy Adult Participants" }, { "s:BriefTitle": "Impact of Passive Heat on Metabolic, Inflammatory and Vascular Health in Persons With Spinal Cord Injury" }, { "s:BriefTitle": "Liquid Biopsies for Improving the Pre-operative Diagnosis of Ovarian Cancer" } ], "success": 1, "cmdname": "query" }, { "data": [ { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University Health Network, Toronto" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of Alabama at Birmingham" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of Alberta" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of California, Irvine" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of California, San Francisco" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of Nebraska" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of North Carolina, Chapel Hill" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of Pennsylvania" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of South Carolina" }, { "LeadSponsorClass": "OTHER", "LeadSponsorName": "University of Wisconsin, Madison" } ], "_comment": "LeadSponsor query", "success": 1, "data-style": "nvp", "cmdname": "query", "data-format": "json" }, { "data": "Rank,NCTId\r\n600,NCT04971304\r\n599,NCT04971317\r\ n598,NCT04971330\r\n597,NCT04971343\r\n596,NCT04971356\r\ n595,NCT04971369\r\n594,NCT04971382\r\n593,NCT04971395\r\ n592,NCT04971408\r\n591,NCT04971421", "_comment": "rank query", "success": 1, "data-style": "colnames", "cmdname": "query", "data-format": "csv" }, { "data": [ [ "Drug", 61 ], [ "Other", 35 ], [ "Device", 19 ], [ "Procedure", 10 ], [ "Behavioral", 9 ], [ "Diagnostic Test", 9 ], [ "Dietary Supplement", 8 ], [ "Combination Product", 3 ], [ "Biological", 2 ] ], "_comment": "count by InterventionTypes", "success": 1, "data-style": "dataonly", "cmdname": "query", "data-format": "json" }, [ { "data": [ "o:FullStudy", "i:FullStudy.Rank", "o:FullStudy.Study", "o:FullStudy.Study.DerivedSection", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionAncestorList", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionAncestorList.ConditionAncestor", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionAncestorList.ConditionAncestor.ConditionAncestorId", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionAncestorList.ConditionAncestor.ConditionAncestorTerm", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseBranchList", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseBranchList.ConditionBrowseBranch", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseBranchList.ConditionBrowseBranch.ConditionBrowseBranchAbbrev", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseBranchList.ConditionBrowseBranch.ConditionBrowseBranchName", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList.ConditionBrowseLeaf", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList.ConditionBrowseLeaf.ConditionBrowseLeafAsFound", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList.ConditionBrowseLeaf.ConditionBrowseLeafId", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList.ConditionBrowseLeaf.ConditionBrowseLeafName", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionBrowseLeafList.ConditionBrowseLeaf.ConditionBrowseLeafRelevance", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionMeshList", "o:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionMeshList.ConditionMesh", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionMeshList.ConditionMesh.ConditionMeshId", "s:FullStudy.Study.DerivedSection.ConditionBrowseModule.ConditionMeshList.ConditionMesh.ConditionMeshTerm", "o:FullStudy.Study.DerivedSection.MiscInfoModule", "s:FullStudy.Study.DerivedSection.MiscInfoModule.VersionHolder", "o:FullStudy.Study.ProtocolSection", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.ArmGroupList", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.ArmGroupList.ArmGroup", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.ArmGroupList.ArmGroup.ArmGroupInterventionList", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.ArmGroupList.ArmGroup.ArmGroupInterventionList.ArmGroupInterventionName", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.ArmGroupList.ArmGroup.ArmGroupLabel", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention", "o:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionArmGroupLabelList", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionArmGroupLabelList.InterventionArmGroupLabel", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionDescription", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionName", "s:FullStudy.Study.ProtocolSection.ArmsInterventionsModule.InterventionList.Intervention.InterventionType", "o:FullStudy.Study.ProtocolSection.ConditionsModule", "o:FullStudy.Study.ProtocolSection.ConditionsModule.ConditionList", "s:FullStudy.Study.ProtocolSection.ConditionsModule.ConditionList.Condition", "o:FullStudy.Study.ProtocolSection.ConditionsModule.KeywordList", "s:FullStudy.Study.ProtocolSection.ConditionsModule.KeywordList.Keyword", "o:FullStudy.Study.ProtocolSection.ContactsLocationsModule", "o:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList", "o:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList.CentralContact", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList.CentralContact.CentralContactEMail", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList.CentralContact.CentralContactName", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList.CentralContact.CentralContactPhone", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.CentralContactList.CentralContact.CentralContactRole", "o:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList", "o:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationCity", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationCountry", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationFacility", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationState", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationStatus", "s:FullStudy.Study.ProtocolSection.ContactsLocationsModule.LocationList.Location.LocationZip", "o:FullStudy.Study.ProtocolSection.DescriptionModule", "s:FullStudy.Study.ProtocolSection.DescriptionModule.BriefSummary", "o:FullStudy.Study.ProtocolSection.DesignModule", "o:FullStudy.Study.ProtocolSection.DesignModule.DesignInfo", "o:FullStudy.Study.ProtocolSection.DesignModule.DesignInfo.DesignObservationalModelList", "s:FullStudy.Study.ProtocolSection.DesignModule.DesignInfo.DesignObservationalModelList.DesignObservationalModel", "o:FullStudy.Study.ProtocolSection.DesignModule.DesignInfo.DesignTimePerspectiveList", "s:FullStudy.Study.ProtocolSection.DesignModule.DesignInfo.DesignTimePerspectiveList.DesignTimePerspective", "o:FullStudy.Study.ProtocolSection.DesignModule.EnrollmentInfo", "s:FullStudy.Study.ProtocolSection.DesignModule.EnrollmentInfo.EnrollmentCount", "s:FullStudy.Study.ProtocolSection.DesignModule.EnrollmentInfo.EnrollmentType", "s:FullStudy.Study.ProtocolSection.DesignModule.PatientRegistry", "s:FullStudy.Study.ProtocolSection.DesignModule.StudyType", "o:FullStudy.Study.ProtocolSection.EligibilityModule", "s:FullStudy.Study.ProtocolSection.EligibilityModule.EligibilityCriteria", "s:FullStudy.Study.ProtocolSection.EligibilityModule.Gender", "s:FullStudy.Study.ProtocolSection.EligibilityModule.HealthyVolunteers", "s:FullStudy.Study.ProtocolSection.EligibilityModule.MinimumAge", "s:FullStudy.Study.ProtocolSection.EligibilityModule.SamplingMethod", "o:FullStudy.Study.ProtocolSection.EligibilityModule.StdAgeList", "s:FullStudy.Study.ProtocolSection.EligibilityModule.StdAgeList.StdAge", "s:FullStudy.Study.ProtocolSection.EligibilityModule.StudyPopulation", "o:FullStudy.Study.ProtocolSection.IdentificationModule", "s:FullStudy.Study.ProtocolSection.IdentificationModule.BriefTitle", "s:FullStudy.Study.ProtocolSection.IdentificationModule.NCTId", "s:FullStudy.Study.ProtocolSection.IdentificationModule.OfficialTitle", "o:FullStudy.Study.ProtocolSection.IdentificationModule.Organization", "s:FullStudy.Study.ProtocolSection.IdentificationModule.Organization.OrgClass", "s:FullStudy.Study.ProtocolSection.IdentificationModule.Organization.OrgFullName", "o:FullStudy.Study.ProtocolSection.IdentificationModule.OrgStudyIdInfo", "s:FullStudy.Study.ProtocolSection.IdentificationModule.OrgStudyIdInfo.OrgStudyId", "o:FullStudy.Study.ProtocolSection.IPDSharingStatementModule", "s:FullStudy.Study.ProtocolSection.IPDSharingStatementModule.IPDSharing", "o:FullStudy.Study.ProtocolSection.OutcomesModule", "o:FullStudy.Study.ProtocolSection.OutcomesModule.PrimaryOutcomeList", "o:FullStudy.Study.ProtocolSection.OutcomesModule.PrimaryOutcomeList.PrimaryOutcome", "s:FullStudy.Study.ProtocolSection.OutcomesModule.PrimaryOutcomeList.PrimaryOutcome.PrimaryOutcomeDescription", "s:FullStudy.Study.ProtocolSection.OutcomesModule.PrimaryOutcomeList.PrimaryOutcome.PrimaryOutcomeMeasure", "s:FullStudy.Study.ProtocolSection.OutcomesModule.PrimaryOutcomeList.PrimaryOutcome.PrimaryOutcomeTimeFrame", "o:FullStudy.Study.ProtocolSection.OutcomesModule.SecondaryOutcomeList", "o:FullStudy.Study.ProtocolSection.OutcomesModule.SecondaryOutcomeList.SecondaryOutcome", "s:FullStudy.Study.ProtocolSection.OutcomesModule.SecondaryOutcomeList.SecondaryOutcome.SecondaryOutcomeDescription", "s:FullStudy.Study.ProtocolSection.OutcomesModule.SecondaryOutcomeList.SecondaryOutcome.SecondaryOutcomeMeasure", "s:FullStudy.Study.ProtocolSection.OutcomesModule.SecondaryOutcomeList.SecondaryOutcome.SecondaryOutcomeTimeFrame", "o:FullStudy.Study.ProtocolSection.OversightModule", "s:FullStudy.Study.ProtocolSection.OversightModule.IsFDARegulatedDevice", "s:FullStudy.Study.ProtocolSection.OversightModule.IsFDARegulatedDrug", "s:FullStudy.Study.ProtocolSection.OversightModule.OversightHasDMC", "o:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule", "o:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule.LeadSponsor", "s:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule.LeadSponsor.LeadSponsorClass", "s:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule.LeadSponsor.LeadSponsorName", "o:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule.ResponsibleParty", "s:FullStudy.Study.ProtocolSection.SponsorCollaboratorsModule.ResponsibleParty.ResponsiblePartyType", "o:FullStudy.Study.ProtocolSection.StatusModule", "o:FullStudy.Study.ProtocolSection.StatusModule.CompletionDateStruct", "s:FullStudy.Study.ProtocolSection.StatusModule.CompletionDateStruct.CompletionDate", "s:FullStudy.Study.ProtocolSection.StatusModule.CompletionDateStruct.CompletionDateType", "o:FullStudy.Study.ProtocolSection.StatusModule.ExpandedAccessInfo", "s:FullStudy.Study.ProtocolSection.StatusModule.ExpandedAccessInfo.HasExpandedAccess", "o:FullStudy.Study.ProtocolSection.StatusModule.LastUpdatePostDateStruct", "s:FullStudy.Study.ProtocolSection.StatusModule.LastUpdatePostDateStruct.LastUpdatePostDate", "s:FullStudy.Study.ProtocolSection.StatusModule.LastUpdatePostDateStruct.LastUpdatePostDateType", "s:FullStudy.Study.ProtocolSection.StatusModule.LastUpdateSubmitDate", "s:FullStudy.Study.ProtocolSection.StatusModule.OverallStatus", "o:FullStudy.Study.ProtocolSection.StatusModule.PrimaryCompletionDateStruct", "s:FullStudy.Study.ProtocolSection.StatusModule.PrimaryCompletionDateStruct.PrimaryCompletionDate", "s:FullStudy.Study.ProtocolSection.StatusModule.PrimaryCompletionDateStruct.PrimaryCompletionDateType", "o:FullStudy.Study.ProtocolSection.StatusModule.StartDateStruct", "s:FullStudy.Study.ProtocolSection.StatusModule.StartDateStruct.StartDate", "s:FullStudy.Study.ProtocolSection.StatusModule.StartDateStruct.StartDateType", "s:FullStudy.Study.ProtocolSection.StatusModule.StatusVerifiedDate", "o:FullStudy.Study.ProtocolSection.StatusModule.StudyFirstPostDateStruct", "s:FullStudy.Study.ProtocolSection.StatusModule.StudyFirstPostDateStruct.StudyFirstPostDate", "s:FullStudy.Study.ProtocolSection.StatusModule.StudyFirstPostDateStruct.StudyFirstPostDateType", "s:FullStudy.Study.ProtocolSection.StatusModule.StudyFirstSubmitDate", "s:FullStudy.Study.ProtocolSection.StatusModule.StudyFirstSubmitQCDate" ], "_comment": "show complete clinical trials attribute structure.", "success": 1, "cmdname": "showattrs" } ] ] Maintain Full use of SQL Functions (currently MySQL) * Aggregate Functions * Date and Time Functions * Numeric Functions and Operators * String Functions and Operators * Cast Functions and Operators * Bit Functions and Operators * Encryption and Compression Functions Example: Create a simple set of 2 Person objects with name and age. Perform an aggregate query returning the CAST of the AVG of the CHAR_LENGTH of their names, the MAX of the their ages, and the COUNT of People. (*) Store ( ) Query ( ) Results [ { "modify": { "data": { "Directory": { "Person": [ { "name": "Sue", "age": 30 }, { "name": "Juniper", "age": 55 } ] } } } } ] [ { "query": { "sfsql": "SELECT CAST( AVG( CHAR_LENGTH( $s:Directory.Person.name)) AS DECIMAL(5,2)) as 'average_name_length', MAX($i:Directory.Person.age) as 'max_age', COUNT(*) as 'person_count'" } } ] [ { "data": [ { "max_age": 55, "average_name_length": 5.0, "person_count": 2 } ], "success": 1, "cmdname": "query" } ] Import Datasets in Batch Mode (This currently requires SFSQL container to be self-hosted. Remote import and self-hosted SFSQL containers will be available soon ) * Use for large datasets (e.g. PubMed, clinicaltrials.gov, etc) * Import raw JSON files without having to perform pre-processing on the files * Import from nested directories of JSON files using wildcard matching without having to write import scripts * Implemented through the modify command's "#include" subcommand * Auto-resume batch from last position processed * See the #include Sub-Command for details Clinical Trial JSON files were downloaded from clinicaltrials.gov. Path to the downloaded JSON files is /var/downloads/samplect/. The SFSQL payload is using the #include subcommand to process the first batch of 100 downloaded source JSON files from this directory. (*) Example Source File ( ) SFSQL Payload { "FullStudy":{ "Rank":699, "Study":{ "ProtocolSection":{ "IdentificationModule":{ "NCTId":"NCT04970017", "OrgStudyIdInfo":{ "OrgStudyId":"17200538" }, "Organization":{ "OrgFullName":"Assiut University", "OrgClass":"OTHER" }, "BriefTitle":"Correlation Between Left Ventricular Global Strain Measured by Speckle Tracking Echocardiography and Scar Burden Measured by Cardiac Magnetic Resonance Imaging in Patients With Ischemic Heart Disease", "OfficialTitle":"Correlation Between Left Ventricular Global Strain Measured by Speckle Tracking Echocardiography and Scar Burden Measured by Cardiac Magnetic Resonance Imaging in Patients With Ischemic Heart Disease" }, "StatusModule":{ "StatusVerifiedDate":"February 2021", "OverallStatus":"Recruiting", "ExpandedAccessInfo":{ "HasExpandedAccess":"No" }, "StartDateStruct": { "StartDate":"January 1, 2021", "StartDateType":"Actual" }, "PrimaryCompletionDateStruct":{ "PrimaryCompletionDate":"January 2022", "PrimaryCompletionDateType":"Anticipated" }, "CompletionDateStruct":{ "CompletionDate":"January 2022", "CompletionDateType":"Anticipated" }, "StudyFirstSubmitDate":"July 16, 2021", "StudyFirstSubmitQCDate":"July 16, 2021", "StudyFirstPostDateStruct":{ "StudyFirstPostDate":"July 21, 2021", "StudyFirstPostDateType":"Actual" }, "LastUpdateSubmitDate":"July 16, 2021", "LastUpdatePostDateStruct":{ "LastUpdatePostDate":"July 21, 2021", "LastUpdatePostDateType":"Actual" } }, "SponsorCollaboratorsModule":{ "ResponsibleParty":{ "ResponsiblePartyType":"Principal Investigator", "ResponsiblePartyInvestigatorFullName":"Mohamed Mahmoud Mohamed Abdellatif", "ResponsiblePartyInvestigatorTitle":"Dr", "ResponsiblePartyInvestigatorAffiliation":"Assiut University" }, "LeadSponsor":{ "LeadSponsorName":"Assiut University", "LeadSponsorClass":"OTHER" } }, "OversightModule":{ "IsFDARegulatedDrug":"No", "IsFDARegulatedDevice":"No" }, "DescriptionModule":{ "BriefSummary":"To verify whether GLS and LV mechanical dispersion, measured by two-dimensional speckle-tracking echocardiography (2D-STE) correlate with LV scar burden measured by cardiac MRI in patients with ischemic heart disease.", "DetailedDescription":"Evaluation of presence, localization, and extent of left ventricular(LV) scar tissue in patients with ischaemic heart disease (IHD) is of fundamental importance in clinical practice. It affects the decision making regarding revascularization and is a determinant of subsequent mortality. (Mele, Fiorencis et al. 2016) Late gadolinium contrast-enhanced cardiac magnetic resonance (LGE-CMR) is considered the current gold standard technique for assessment of the scar burden in IHD patients. However, it is not readily accessible in many areas due to availability and cost issues. (Abou, Prihadi et al. 2020), (Bendary, Afifi et al. 2019) Several recent studies suggested 2-D speckle tracking strain as a potential surrogate for cardiovascular magnetic resonance (CMR) late gadolinium enhancement (LGE) imaging. This would be useful in cases where CMR is not available, gadolinium contrast is contraindicated, or in patients at greater risk of adverse long term events. (Erley, Genovese et al. 2019) Among echocardiography derived strain measurements, global longitudinal strain (GLS) was shown to be superior to global circumferential strain (GCS) in its ability to detect subtle myocardial abnormalities due to better reproducibility (Erley et al, 2019). Left ventricular mechanical dispersion (LVMD) is also considered a valuable parameter that was associated with outcomes after myocardial infarction. (Abou, Prihadi et al. 2020).\n\nDespite the growing number of strain related studies in the literature, it is not clear whether the relationship of strain measurements with LGE is strong enough for strain to be considered as a surrogate. (Erley, Genovese et al. 2019). Also, the differences between GLS and LV MD among strain components in this context are not well established." }, "ConditionsModule":{ "ConditionList":{ "Condition":[ "Ischemic Heart Disease" ] } }, "DesignModule":{ "StudyType":"Observational", "PatientRegistry":"No", "DesignInfo":{ "DesignObservationalModelList":{ "DesignObservationalModel":[ "Case-Only" ] }, "DesignTimePerspectiveList":{ "DesignTimePerspective":[ "Cross-Sectional" ] } }, "EnrollmentInfo":{ "EnrollmentCount":"51", "EnrollmentType":"Anticipated" } }, "ArmsInterventionsModule":{ "InterventionList":{ "Intervention":[ { "InterventionType":"Radiation", "InterventionName":"Cardiac MRI, Echocardiography", "InterventionDescription":"Magnetic resonance imaging, Echocardiography" } ] } }, "OutcomesModule":{ "PrimaryOutcomeList":{ "PrimaryOutcome":[ { "PrimaryOutcomeMeasure":"Scare burden by echocardiography", "PrimaryOutcomeDescription":"To test the correlation between the scar burden measured by cardiac MRI and GLS measured by 2D STE", "PrimaryOutcomeTimeFrame":"One year" } ] }, "SecondaryOutcomeList":{ "SecondaryOutcome":[ { "SecondaryOutcomeMeasure":"Value of spickle tracking echocardiography in clinical practice", "SecondaryOutcomeDescription":"Predicting the scar burden in ICMP patients by GLS and mechanical dispersion.", "SecondaryOutcomeTimeFrame":"One year" } ] } }, "EligibilityModule":{ "EligibilityCriteria":"Inclusion Criteria:\n\n* Patients presenting for viability assessment in to cardiac MRI unit, Assiut university heart hospital, with a history of previous stemi, at least 3 months after the acute event ( scar stabilization) and up to one year\n\ nExclusion Criteria:\n\nPatients with:\n\nContraindication to cardiac MRI (claustrophobia, Patients with eGFR below 30 mL/min/1.73 m2. and patients with metallic implants)\nNon-ischemic cardiomyopathy.\ nValvular heart disease (VHD).", "Gender":"All", "StdAgeList":{ "StdAge":[ "Child", "Adult", "Older Adult" ] }, "StudyPopulation":"Patients presenting for viability assessment in to cardiac MRI unit, Assiut university heart hospital, with a history of previous stemi, at least 3 months after the acute event ( scar stabilization) and up to one year", "SamplingMethod":"Non-Probability Sample" }, "ContactsLocationsModule":{ "CentralContactList":{ "CentralContact":[ { "CentralContactName":"Mohamed Abdellatif, MSC", "CentralContactRole":"Contact", "CentralContactPhone":"+201001073747", "CentralContactEMail":"mohamed.abdellatief@med.au.edu.eg" },{ "CentralContactName":"Shimaa Sayed Khidr, PHD", "CentralContactRole":"Contact", "CentralContactPhone":"+201001346551", "CentralContactEMail":"S.khidr@aun.edu.eg" } ] }, "OverallOfficialList":{ "OverallOfficial":[ { "OverallOfficialName":"Mohamed Abdellatif", "OverallOfficialAffiliation":"Assiut University", "OverallOfficialRole":"Principal Investigator" } ] }, "LocationList": { "Location":[ { "LocationFacility":"Assiut university", "LocationStatus":"Recruiting", "LocationCity":"Assiut", "LocationZip":"71511", "LocationCountry":"Egypt", "LocationContactList":{ "LocationContact":[ { "LocationContactName":"Mohamed Abdellatif", "LocationContactRole":"Contact", "LocationContactPhone":"00201001073747", "LocationContactEMail":"Mohamed.abdellatief@med.au.edu.eg" } ] } } ] } } }, "DerivedSection":{ "MiscInfoModule":{ "VersionHolder":"July 27, 2021" }, "ConditionBrowseModule":{ "ConditionMeshList":{ "ConditionMesh":[ { "ConditionMeshId":"D000006331", "ConditionMeshTerm":"Heart Diseases" },{ "ConditionMeshId":"D000017202", "ConditionMeshTerm":"Myocardial Ischemia" },{ "ConditionMeshId":"D000003324", "ConditionMeshTerm":"Coronary Artery Disease" },{ "ConditionMeshId":"D000007511", "ConditionMeshTerm":"Ischemia" } ] }, "ConditionAncestorList":{ "ConditionAncestor":[ { "ConditionAncestorId":"D000010335", "ConditionAncestorTerm":"Pathologic Processes" },{ "ConditionAncestorId":"D000002318", "ConditionAncestorTerm":"Cardiovascular Diseases" },{ "ConditionAncestorId":"D000014652", "ConditionAncestorTerm":"Vascular Diseases" },{ "ConditionAncestorId":"D000003327", "ConditionAncestorTerm":"Coronary Disease" },{ "ConditionAncestorId":"D000001161", "ConditionAncestorTerm":"Arteriosclerosis" },{ "ConditionAncestorId":"D000001157", "ConditionAncestorTerm":"Arterial Occlusive Diseases" } ] }, "ConditionBrowseLeafList":{ "ConditionBrowseLeaf":[ { "ConditionBrowseLeafId":"M9126", "ConditionBrowseLeafName":"Ischemia", "ConditionBrowseLeafAsFound":"Ischemic", "ConditionBrowseLeafRelevance":"high" },{ "ConditionBrowseLeafId":"M8002", "ConditionBrowseLeafName":"Heart Diseases", "ConditionBrowseLeafAsFound":"Heart Disease", "ConditionBrowseLeafRelevance":"high" },{ "ConditionBrowseLeafId":"M18089", "ConditionBrowseLeafName":"Myocardial Ischemia", "ConditionBrowseLeafAsFound":"Ischemic Heart Disease", "ConditionBrowseLeafRelevance":"high" },{ "ConditionBrowseLeafId":"M5129", "ConditionBrowseLeafName":"Coronary Artery Disease", "ConditionBrowseLeafAsFound":"Ischemic Heart Disease", "ConditionBrowseLeafRelevance":"high" },{ "ConditionBrowseLeafId":"M4743", "ConditionBrowseLeafName":"Cicatrix", "ConditionBrowseLeafRelevance":"low" },{ "ConditionBrowseLeafId":"M5132", "ConditionBrowseLeafName":"Coronary Disease", "ConditionBrowseLeafRelevance":"low" },{ "ConditionBrowseLeafId":"M15983", "ConditionBrowseLeafName":"Vascular Diseases", "ConditionBrowseLeafRelevance":"low" },{ "ConditionBrowseLeafId":"M3050", "ConditionBrowseLeafName":"Arteriosclerosis", "ConditionBrowseLeafRelevance":"low" },{ "ConditionBrowseLeafId":"M3046", "ConditionBrowseLeafName":"Arterial Occlusive Diseases", "ConditionBrowseLeafRelevance":"low" } ] }, "ConditionBrowseBranchList":{ "ConditionBrowseBranch":[ { "ConditionBrowseBranchAbbrev":"BC23", "ConditionBrowseBranchName":"Symptoms and General Pathology" },{ "ConditionBrowseBranchAbbrev":"All", "ConditionBrowseBranchName":"All Conditions" },{ "ConditionBrowseBranchAbbrev":"BC14", "ConditionBrowseBranchName":"Heart and Blood Diseases" } ] } } } } } } [ { "modify": { "data": { "ctroot": { "ct": [ { "#set": {} }, { "# include": { "files": [ { "dir": "/var/downloads/samplect/", "fpat": "*/*.json" } ], "batch": { "id": "casestudies", "size": 100 } } } ] } } } } ] A JSON-over-HTTP API * Access SFSQL from any language supporting HTTP and JSON * Receive results in Data Formats of JSON (default) and CSV * Receive results in Data Styles such as name-value-pairs(default), data-only, and headers-in-first-row (a result style of JSON-Graph is on the roadmap) * Issue Multiple Commands in one HTTPS request, reducing API round trips. Use Cloud SFSQL by simply issuing a HTTPS POST to your dedicated endpoint. The POST contains a SFSQL-compliant JSON payload (see examples throughout site). SchemafreeSQL - Diagram Is SFSQL right for you? [ ] Do you know SQL? Great! Then learning how to query in a join-less yet deep fashion across object-related schemaless data will only take seconds. SchemafreeSQL's query language uses the SQL constructs you are already familiar with (e.g. GROUP BY, ORDER BY, LIMIT) but frees you from JOINS when querying across deep structure. [ ] Do you need NoSQL features? NoSQL databases typically provide features such as schemaless data storage, ease of use, and fast queries without (much) optimization. SchemafreeSQL provides all these NoSQL features and more. [ ] Does "chasing" schemaless data with indexes sound like a hassle? It is! Many NoSQL solutions will not query at adequate speeds until indexes are created. The problem is that schemaless structures are by definition not defined until data is stored. You therefore need to "chase" your changing structures with manually-created indexes. Not only that, but choosing WHICH attributes to index must also be dealt with. See "Index Permutation Limitation" for more detail on this problem. SchemafreeSQL requires zero indexing regardless of the complexity of your structures. [ ] Would you like to store Object References? References avoid redundancy and ease management. A capability outside of JSON column types and most NoSQL collections. SchemafreeSQL allows you to store a reference to any attribute under any attribute (e.g. Two spouses sharing the same address) without prior setup of schemas or foreign keys constraints. [ ] Do you need to query deep structures? SchemafreeSQL allows you to query your deeply-related schemaless data using SQL syntax - optionally including any of the built-in functions that your SQL database provides - but without having to write JOIN clauses. The relationships within your data structure are naturally maintained within your database by SchemafreeSQL. [ ] Would you like to avoid juggling multiple database systems? Integrating a new underlying database system to run alongside your SQL database is more than just a learning curve. There is also the cost and time that needs to spent installing, optimizing and maintaining that additional (NoSQL?) database system. SchemafreeSQL avoids all that by using your existing SQL database system and all of it's existing advantages and providing a familiar SQL syntax for querying. And since the data you store in SchemafreeSQL is part of your current SQL database, your existing backup routines usually only need subtle changes to cover your new data. [ ] Do your schemaless data storage requirements fall somewhere below "big data"? Schemafree has many advantages, but as with most tech you must balance the pros and cons. For instance, Schemafree performs various referential data integrity checks on inserts and as such cannot be expected to perform inserts as fast as less feature-filled systems inserting flat data sets into big-data sized repositories. However, as SchemafreeSQL is implemented over next-gen scalable SQL databases, we may find that in many cases tradeoffs such as these are nullified. SFSQL extends your SQL Database This opens up the possibility that your current SQL database can provide most/all of your required DB features instead of juggling multiple systems. NOTE: The categories SQL, SQL w/JSON support and NoSQL are general and do not perfectly cover every product under them. Some products buck the general trend and might be listed opposite of what is shown for their category. SFSQL SQL SQL w/JSON support NoSQL Query across dynamic combinations of newly-added data attributes without having to create indexes, optimize indexes or risk full-table scans due to missing indexes. SFSQL effectively handles the "Index Permutation Limitation". See FAQ: optimization-free Query deep relationships without JOIN syntax Query deep relationships across data boundaries (e.g "tables","collections","documents") with a consistent SQL syntax Insert Schemaless data at runtime Insert Schemaless data across "collections"/"documents" in a single Payload Insert Schemaless Objects sourced from unmodified JSON files in batch mode, spanning multiple directories if needed, within a single Payload NoSQL + SQL Resources FAQ Docs Pricing Create AccountSign In Support Contact Support/Feedback Portal GitHub Email:support@schemafreesql.zohodesk.com Twitter Give Feedback Legal Privacy End User License Agreement Terms Of Service (c) 2012-2023 Xornet, Inc.