03 · What You Need to Know
What Actually Changes From One Database to Another?
A Search Strategy Has Two Layers: Logic and Syntax
The easiest way to understand database differences is to separate what you want the search to accomplish from how one particular platform expresses it.
Search logic
The concepts, alternative terms, relationships, fields, and retrieval decisions you intend the search to represent.
Search syntax
The database-specific commands, symbols, field codes, operators, and formatting used to express those decisions.
Suppose one concept in your search is teacher burnout. Your retrieval intention might be to find teacher-related terms within a few words of burnout-related terms in titles and abstracts.
That intention can remain the same across databases. The proximity operator, field code, truncation symbol, and exact query structure may not.
This distinction is the foundation for understanding why a search must later be translated from one database to another.
The Database and the Search Platform Are Not Always the Same Thing
Researchers often use database and platform as though they were interchangeable. They are not always.
A bibliographic database is the indexed collection of records. A search platform or interface is the system through which you search that collection. The same or related databases may sometimes be available through different providers, and the search syntax can depend on the interface.
For example, a database searched through an EBSCOhost interface uses EBSCO's search functionality and field conventions. A database available through another provider may expose different operators, codes, defaults, or thesaurus functions even when much of the underlying bibliographic content overlaps.
When documenting or translating a strategy, record both the database and the platform where that distinction matters.
Boolean Logic Is Widely Shared, but Even Boolean Behavior Needs Checking
AND, OR, and NOT are among the most widely recognized search operators. Their underlying logic is broadly consistent: AND intersects sets, OR provides alternative routes, and NOT excludes records.
But platforms can differ in details such as capitalization requirements, implicit operators, precedence rules, and how Boolean expressions interact with automatic search processing.
ProQuest, for example, currently assumes AND between ordinary search terms when no operator is supplied and documents a precedence order in which proximity operators are evaluated before AND, OR, and NOT. It also allows parentheses to override its default precedence.
PubMed likewise supports AND, OR, and NOT, but its ordinary searches are also processed through PubMed-specific mechanisms such as Automatic Term Mapping.
Knowing what Boolean operators conceptually do is therefore necessary but not sufficient. You must also know how the particular platform processes the query containing them.
Parentheses May Be Portable, but the Rules Around Them May Not Be
The conceptual use of parentheses is broadly transferable: group terms that should function together before combining them with other parts of the search.
For example:
(adolescent OR teenager) AND depression
expresses a clear conceptual structure.
But the surrounding parser still follows platform-specific rules. ProQuest explicitly documents parentheses as a way to build nested queries and override its normal operator precedence.
This is why explicit grouping remains useful even when you think you know the platform's default order of operations. It makes the intended structure visible and reduces dependence on implicit parser behavior.
Phrase Searching Can Change More Than Word Order
Double quotation marks are commonly associated with phrase searching, but they are not a universal promise that every system will process the enclosed words identically.
ProQuest currently uses quotation marks for phrase searching. Its search system also performs automatic spelling and grammatical variation in ordinary searches, and quotation marks can be used to override that behavior for an exact word form.
PubMed behaves differently. Quoted phrases interact with its phrase index and Automatic Term Mapping. Its documentation explains that forcing a phrase can alter the automatic translation that an unquoted query would otherwise receive.
The same visible punctuation can therefore participate in different retrieval systems.
Watch Out
Do not assume that quotation marks merely tell every database to "search these exact words together." Check whether they also disable automatic mapping, suppress word variants, depend on a phrase index, or otherwise alter the platform's normal processing.
Truncation Symbols and Rules Are Database-Specific
Truncation is conceptually simple: search a stable word stem while allowing additional characters. The syntax is not universal.
An asterisk is commonly used, but what it means, where it may appear, how many characters it can replace, and whether it interacts with automatic mapping can vary.
ProQuest currently uses * for truncation and supports defined truncation using a form such as [*n]. Its documentation also specifies restrictions on where truncation symbols can appear.
PubMed also uses *, but calls it a wildcard representing zero or more characters. PubMed requires at least four characters before the first wildcard and changes ordinary query processing when a wildcard is used.
So even when two systems both recognize an asterisk, that does not make their wildcard or truncation behavior identical.
Wildcard Symbols Are Even Less Portable
A wildcard usually substitutes for variable characters, but platforms differ in the symbols and number of characters represented.
ProQuest currently uses? as a wildcard representing zero or one character and * for truncation, while also supporting internal use of * in appropriate terms.
Another interface may use? for exactly one character, # for a variation, or another convention entirely. Some systems distinguish internal wildcards from right-hand truncation; others use the same symbol for several functions.
This is why the advice to "use * for truncation and? for wildcards" should never be treated as a universal rule.
Proximity Searching Has No Universal Operator
Proximity syntax is one of the clearest examples of platform variation.
The underlying intention might be:
Find teacher and burnout within five words of each other.
But one platform might express that relationship with NEAR, another with N, another with W, another with ADJ, and another through a field-specific proximity construction.
ProQuest currently supports NEAR/n or N/n for terms occurring within a specified distance in either order, and PRE/n or P/n when the first term must precede the second.
PubMed uses a completely different form:
This is why proximity searching must be understood conceptually before its syntax can be translated.
The Same Proximity Number May Not Mean the Same Distance
Even after identifying the correct operator, the number following it may be interpreted differently.
Some platforms describe the number as the number of words separating the terms. Others define a maximum word distance or span according to their own implementation. Ordered and unordered proximity can also behave differently.
Consequently, changing NEAR/5 into ADJ5 simply because both contain the number five may not preserve the original retrieval relationship.
Translate the intended closeness, not merely the visible number.
Some Operators Cannot Be Combined in the Same Way Everywhere
A search expression may be valid because one platform permits several search features to interact. The destination system may prohibit that combination.
PubMed provides a useful example: its current proximity search is not compatible with wildcards. If a wildcard appears within the quoted terms of a proximity expression, PubMed ignores the proximity operator. Automatic Term Mapping is also not applied to proximity-search terms.
Another database may permit truncation inside a proximity expression.
This creates a particularly dangerous translation error because the copied query may not necessarily produce an obvious syntax failure. It may run while silently behaving differently.
Field Codes Differ Across Platforms
Field searching tells a database where a term should match, but the codes used to express those fields are platform-specific.
PubMed uses codes such as [ti] for Title and [tiab] for Title/Abstract.
ProQuest supports named field expressions such as TITLE(term) and ABSTRACT(term), along with many other database-dependent field codes.
A field code that is meaningful in one platform can therefore be meaningless or misinterpreted in another.
Similarly Named Fields May Not Search the Same Metadata
Translation requires more than replacing one code with another.
A field called Topic in one database may search a combination of titles, abstracts, author keywords, and generated indexing. A field called Keyword elsewhere may mean author keywords, controlled terms, or a broader platform-defined search.
Even Title/Abstract is not necessarily a literal description of only those two pieces of text. As discussed when deciding where a keyword should be searched, the field definition matters more than its label.
When translating a field restriction, ask what information the original field was intended to search and identify the closest functional equivalent in the destination database.
Default Searches Can Cover Different Fields
Typing an untagged term into the main search box does not produce a universal "keyword search."
ProQuest's current documentation states that its ordinary search can look across multiple fields, including titles, authors, subjects, and full text, depending on platform configuration.
PubMed's ordinary untagged search uses its own Automatic Term Mapping process and bibliographic fields rather than functioning as an unrestricted full-text search.
Two interfaces can therefore receive the same plain-language query and search fundamentally different textual and indexed material.
Automatic Term Processing Differs Substantially
Modern search platforms frequently do more than literal character matching.
PubMed uses Automatic Term Mapping for many untagged queries. It may map terms to MeSH concepts and other equivalents as part of search translation. Special syntax such as field tags, wildcards, proximity expressions, and quoted phrases can alter that behavior.
ProQuest currently applies spelling and grammatical variants in ordinary searching, including British and American spelling differences and some singular, plural, and comparative forms. Quotation marks can override those variants.
Thus, even before you add sophisticated syntax, the search engines may be expanding your terms in different ways.
| Search Feature |
What May Differ Across Databases |
Translation Question |
| Boolean operators |
Implicit operators, precedence, capitalization, parser rules |
Does the same concept grouping still execute? |
| Phrase searching |
Quotation behavior, phrase indexes, automatic expansion |
Does the phrase search preserve the intended wording without losing useful mapping? |
| Truncation |
Symbol, minimum stem, character limits, automatic processing |
Which syntax captures the intended word forms? |
| Wildcards |
Symbol and number of characters represented |
How should predictable spelling variation be expressed? |
| Proximity |
Operator, distance calculation, word order, field availability |
What is the functional equivalent of the intended textual closeness? |
| Fields |
Codes and field definitions |
Which destination field searches equivalent metadata? |
| Subject headings |
Vocabulary, hierarchy, explosion, qualifiers |
How does the destination database index the same concept? |
| Automatic processing |
Mapping, spelling variants, stemming, synonyms |
What does the platform add or transform automatically? |
Controlled Vocabularies Are Database-Specific
Syntax is only part of translation. The vocabulary itself may change.
MEDLINE uses Medical Subject Headings (MeSH). Embase uses Emtree. APA PsycInfo has the APA Thesaurus of Psychological Index Terms. CINAHL has its own subject-heading system.
A MeSH descriptor cannot simply be pasted into another database and assumed to function as that database's controlled-vocabulary search.
You may still use the same phrase as a free-text keyword if it is appropriate, but that is a different retrieval route. The destination database's controlled vocabulary should be searched for the corresponding concept.
Even Similar Subject-Heading Systems May Organize Concepts Differently
Two controlled vocabularies can contain apparently similar terms while differing in scope, hierarchy, preferred terminology, and indexing policy.
A broad heading in one system may correspond to several narrower headings in another. A concept may have a dedicated descriptor in one vocabulary but require a combination of terms in another.
Translation is therefore conceptual rather than lexical. Ask how the destination database represents the idea, not merely whether it recognizes the same words.
Subject-Heading Explosion Can Behave Differently
Hierarchical controlled vocabularies often allow a broader term to include narrower terms beneath it, commonly called exploding the heading.
But interfaces differ in whether explosion is automatic, optional, or expressed through particular syntax. Qualifiers or subheadings can also work differently.
A search that depends on a MeSH heading plus automatic inclusion of narrower concepts must therefore be reconstructed carefully in a database whose thesaurus uses another hierarchy.
Database Coverage Also Changes the Results Even When the Syntax Is Equivalent
Suppose you successfully reproduce the same conceptual search in two databases. You should still expect different results.
The databases may index different journals, conference proceedings, books, disciplines, publication types, languages, or historical periods. They may also contain overlapping records with different metadata.
This distinction is critical:
Different results because the search was translated differently
A methodological issue that may require correction.
Different results because the databases contain different records
An expected consequence of searching different information sources.
Identical result counts are neither expected nor desirable as a translation target.
The Same Article May Be Represented Differently Across Databases
Even when two databases contain the same article, its searchable record may differ.
One database may supply controlled subject headings. Another may provide different indexing terms. Author keywords may be present in one record and absent from another. Abstract text can vary by source or record processing.
As a result, a translated search can behave differently at the individual-record level even when the underlying conceptual logic is carefully preserved.
Full-Text Defaults Can Differ Too
Some search platforms include full text in their default search environment; others primarily search bibliographic metadata.
ProQuest explicitly notes that administrators can configure whether ordinary searching includes full text by default, although users can still target fields directly.
This means that even two users of the same broad platform may need to pay attention to configuration and selected databases.
When full-text searching is involved, resource coverage and searchable fields become part of the translation problem.
Interface Updates Can Make Old Search Advice Obsolete
Database platforms change.
Operators are added, interfaces are redesigned, field behavior changes, automatic processing is modified, and documentation is updated. PubMed's proximity searching is a useful example: it was introduced in 2022, so older guidance stating that PubMed does not support proximity searching is now outdated.
This is why a search guide, thesis, or published review can be a useful model but should not be treated as current technical documentation.
For database mechanics, verify against the platform's current official help pages.
A Query That Runs Without an Error Can Still Be Wrong
Syntax errors are convenient because the database tells you something is wrong.
Silent differences are more dangerous.
A platform may treat an unfamiliar operator as an ordinary word. It may ignore unsupported punctuation. A wildcard may disable automatic mapping. A field code may target a different metadata element than expected. A proximity expression may run but impose a different word-order condition.
The search can therefore look successful while representing a different retrieval strategy.
Watch Out
"The database accepted my query" is not evidence that the search was translated correctly. Check the platform's documentation, query details where available, and the behavior of representative search terms.
Result Counts Can Help Diagnose Translation Problems
You should not expect the same number of records across databases, but unexpectedly dramatic changes can still be informative.
Suppose a concept block retrieves 8,000 records in one database and 40 records in another database of comparable disciplinary relevance. The difference may be legitimate, but it deserves investigation.
Check:
- whether the free-text fields are equivalent;
- whether truncation worked;
- whether the controlled-vocabulary term exists and was searched correctly;
- whether phrase syntax became too restrictive;
- whether proximity was translated correctly;
- whether an automatic mapping feature was lost;
- whether the destination database simply has substantially different coverage.
Result counts are diagnostic clues, not equivalence targets.
Known Relevant Articles Are Better Translation Tests Than Matching Counts
If you know several articles that should be retrievable, check whether the translated strategy finds them in databases that actually index those records.
If a known relevant article is present in the destination database but the translated search misses it, inspect why. Perhaps the subject heading differs. Perhaps the title/abstract field excludes author keywords that were searched elsewhere. Perhaps the proximity expression became too restrictive.
Known-item testing does not prove completeness, but it can reveal translation failures that aggregate result counts conceal.
Translate One Component at a Time
Large search strings are difficult to debug. A safer workflow is to translate each feature deliberately.
Concepts Preserve what the search is trying to represent.
Controlled vocabulary Find the destination database's appropriate subject headings.
Free-text terms Retain relevant terminology while checking automatic spelling and word-form processing.
Fields Map each original search field to the closest functional destination field.
Operators Translate phrases, truncation, wildcards, proximity, Boolean grouping, and exclusions using current platform rules.
Test Compare query behavior, inspect representative results, and check known relevant records.
This workflow reduces the chance that several syntax differences will be introduced simultaneously and then become impossible to diagnose.
Do Not Optimize Every Database Into the Same Search String
A translated strategy does not have to look identical across platforms.
One database may have an excellent controlled vocabulary for your concept. Another may depend more heavily on free-text searching. One may support a useful proximity operator. Another may require several phrase variants instead. One field may include author keywords automatically, while another requires them to be searched separately.
Functional equivalence is more important than visual symmetry.
A set of database searches that all look exactly alike can actually be a warning sign that the platform-specific features were not considered.
Database-Specific Adaptation Is Part of Search Quality, Not a Reproducibility Problem
Researchers sometimes worry that changing syntax between databases makes the search less standardized.
The opposite is often true. Reproducibility requires documenting what was actually searched in each resource, not pretending that different systems behave identically.
For formal reviews, report the database, platform, search date, and exact strategy as appropriate to the reporting standard being followed. This allows readers to see how the same conceptual search was implemented across different systems.
Consistency should exist at the level of the research question and retrieval logic. Technical implementation should respect the database being searched.
